Domain Driven Design (DDD) is a particular way to structure your app.
Posted by trolleid@reddit | programming | View on Reddit | 81 comments
Posted by trolleid@reddit | programming | View on Reddit | 81 comments
FraTe7@reddit
Do we really need a name (DDD) for this? Feels like selling buzzwords 🤣
All_Up_Ons@reddit
I don't think this post is a particularly good introduction to DDD, but don't let that distract you. The important thing is that DDD is probably the correct way to organize your codebase. Why? Because it focuses on things that matter (business domains) instead of things that don't (microservices vs monolith, is this microservice really micro enough, etc).
tom_swiss@reddit
Seems like a reinvention of entity-relationship modelin.
gladfelter@reddit
I mostly sgree and I'm a big fan of DDD. But.... If you share domain code across binaries that might mix versions in production, you're in for a bad time. Experiments can help, but it's still risky.
modestlife@reddit
Well, the idea is to organise your solution space (services, microservices, modules, different apps, etc.) to follow your problem space (bounded contexts, domains, subdomains, etc.).
So there should not be a "shared domain across binaries". Because that would mean your system's solution space/architecture dictates how your problem space/business domain, instead of the other way around.
Zardotab@reddit
I don't know about e-commerce (where microservices thrive), but for most rank and file biz and admin apps, there is often no such thing as true independence: most things intertwine to various degrees.
Fairly arbitrarily lines are drawn in the sand to be able to manage complexity as humans with limited brains: Conway's Law. To pretend one can just pull the plug on a notable portion of a system and everything else continue on fine is usually a pipe dream.
Luolong@reddit
Most “rank and file biz and admin apps” are steaming piles of hacks layered upon hacks layered upon quick hacks to get some POC working and into production. There might have been an overarching architecture once upon a time when the original POC was developed, but nobody even remembers who were the original developers and there’s no one to ask.
anon_cowherd@reddit
So are the businesses themselves. They've years and years of rules and processes made by humans for humans. Attempting to codify the business domain into code is initially impossible to do cleanly, because you'll get different answers from different people, you'll find circular dependencies, informal solutions to gaps in formal things.
One of the best parts about DDD - if you have the time to do it, and do it well - is forcing the business side to make decisions and actually come to a common understanding and formalizing it.
VictoryMotel@reddit
This is vague pablum and doesn't mean anything.
gladfelter@reddit
Differing domains is only one reason to segregate the codebase by deployments. Many nonfunctional characteristics matter. So you do end up having a pressure to structure your codebase around binaries first and domains second.
Venthe@reddit
I've been building DDD specifically for the past 8 years, and I've seen even more. I've yet to see the precedence im of binaries over a domain.
You always place the domain first, then - if non-functional requirements put the pressure on - you do the funky stuff within the domain
gladfelter@reddit
I've worked on world-scale online payments systems and app productivity suites for 15 years and I've seen some stuff.
Version skew is insidious because it breaks the abstraction in developers' minds as they plan features and rollouts. It's very error-prone.
You have to lean towards domains inside of binaries and version-safe interfaces between binaries with the kinds of systems that I'm talking about. Nothing else scales to that level without correctness and availability problems. There are auxilliary and horizontal concerns that can be shared to some degree such as security, since a lot of the time security is evaluated multiple times in the request trace since detecting it earlier leads to better customer experience (such as greying out options that aren't available vs erroring out when the deepest gatekeeer rejects.)
I've written a bit more about my experiences here if you're curious:
https://testing.googleblog.com/2017/02/discomfort-as-tool-for-change.html
Venthe@reddit
We'd have to disagree here. While I personally have only worked on broadly defined finance on a country scale, my colleagues did work on a world-scale e-commerce. And while there are issues with versions (as in any evolving interface) I fail to see the necessity to organize the code around the deployment units; and I've literally never seen the requirement for a single deployment unit to have the code from two domains.
...which has nothing to do with the deployment unit still.
Not today, but I'll definitely take a look when I have time, thanks!
F5x9@reddit
Is “event storming” a real thing?
Fine_Tie_1576@reddit
It is a very powerful technique! It has 3 levels: Big Picture, Process Modeling and Software Design. There are several great online tools that support Event Storming that you could try: Collaborative whiteboards like Miro, Mural and Creately, which provide a shared digital space for participants to add "sticky notes" and create diagrams. Another options is Qlerify, which provides more structure and can use AI to generate event storming flows and domain models.Â
All_Up_Ons@reddit
I've never used it. Seems like an unrelated method for brainstorming a system from scratch.
Venthe@reddit
Or mapping the actual business for the purpose of directing the architecture.
Very useful. As a technique itself, it tends to uncover a lot of knowledge that is usually implicit. This allows both the architecture and the code itself to actually reflect how business operates which directly translates to the ease of change, ease of maintenance and the future capabilities of the system.
felicity_uckwit@reddit
Yes. And it is useful. These days I consider it a precursor to this:Â
https://eventmodeling.org/posts/what-is-event-modeling/
I've used this with event driven architectures, and with more traditional systems, to figure out data requirements from high level views of processes and their key stages.Â
Scavenger53@reddit
https://www.eventstorming.com/
its just a way to plan with sticky notes
martinator001@reddit
I've read it and to me it actually does seem solid. But I would simplify it - KISS
agumonkey@reddit
not long after starting my career, all the java chops i cared about became secondary
implementation details are transient, therefore not super important, whereas being able to ensure the business domain match as close to 100% as possible is a life saver
SuspiciousDepth5924@reddit
I have some very mixed feeling about "DDD", I think there are some good ideas there; but on the other hand the absolute worst codebases I've ever worked with was the ones designed by "DDD"-architects.
I like that it tries to separate functional/business logic from purely technical stuff, what database the application is using should have no bearing on whether you are eligible for a loan.
I like that it tries to bridge the gap between developers and stakeholder by using "Ubiquitous Language" (while I like the concept I admittedly loathe that term, it gives me way too much "I love the smell of my own farts" vibes).
I don't like that it horizontally slices the code in a way that you have to navigate between multiple deeply nested directories to get the full end-to-end context of a feature. Having parts of the feature deep in /application/.../foo, /infrastructure/.../foo and /domain/.../foo just makes it harder to work with. Despite talking a lot about bounded-contexts, I find DDD-evangelists generally care more about over-complicated folder structures and horizontal slices...
I suspect the "Domain Events" probably refer to "some domain stuff that happens" rather than events in the sense of "pub-sub", however I find DDD-codebases often are very liberal with the use of pub-sub for internal communications, something that makes it significantly harder to trace the data and control flow of the application.
I often feel like the DDD aggregates are often used as band-aid solution over the root issue of trying to maintain invariants of shared mutable data. Also I often find that the aggregates are often far too large, which means the load on the db is far larger than it has any right to be (and far too much waiting on locks).
My experience with DDD in practice so far has not been great. What it often has amounted to is over complicated architecture with very strong but implicit coupling and convoluted folder structure. Again I think there are some good ideas there, but I think "functional core, imperative shell" is generally a much better approach to building applications.
_indi@reddit
The Application/Domain/Infrastructure separation is more of an aspect of a layered architecture such as onion/clean/hexagonal rather than DDD itself.
I personally like it sliced that way.
Hidden_driver@reddit
DDD is bloat that boomers invented for big big applications. 99% applications can do just a simple controller -> service -> db 3 layer architecture and be successful. Even the MS Clean architecture is bloated and contains useless steps.
recaffeinated@reddit
99% of applications just have 1 controller, 1 service and 1 DB?
Because if you have more than that you have to decide where to put things and suddenly DDD is very relevant to you.
My entire career has basically been spent using DDD to rewrite applications that people didn't think about enough when they got started.
If you're building a toy that you don't plan to try to scale then sure, just chuck your code into whatever design you want. If you want it to be able to expand and broaden, then you want a plan for how different systems will interact and where their boundaries are.
Kirk_Kerman@reddit
DDD in my experience is really quite good if you're one team out of many in a large org working in a mature domain and you need the code to reflect and enforce your boundaries. I'd you're a small team it's the wrong call. If you're doing something new, it's the wrong call.
Venthe@reddit
I'd have to completely disagree. As long as you have a rich domain - and you have one, somehow I doubt that your business is built on the CRUD - DDD is a must, and the boundaries provided by the context are must as well.
The amount of times that I've seen a "good technical" solution that was impossible to extend just because domain was not placed at the center is, well, too much.
Kirk_Kerman@reddit
I've mostly been at startups and sometimes they let the DDD guy go wild with it. It adds an enormous amount of inertia that we don't need when there's 3 devs total and the entire infrastructure demand is met by a single EC2 without a load balancer. I've seen it used at big orgs and it works great there because you really really need to keep the lines clean.
GrammerJoo@reddit
This actually shows that DDD is often misunderstood. It's a sickness in our industry that we tend to not learn, repeat mistakes of the past, and reinvent old ideas again and again.
morricone42@reddit
If a pattern is that often misunderstood then maybe the problem is with the pattern itself.
Venthe@reddit
No, it only means that it is non-trival and ultimately used by laypeople.
How much training did you need to be efficient at programming? How much time do engineers need to master their field? I assure you, most of the developers never actually learn the core skills beyond surface level understanding. Agile, DevOps, DDD... Hell, how much time did people spend actually learning git their second most often tool?
Because people are always surprised when they learn about the reflog; and you expect a proficiency over a set of patterns which require months of actual directed practice?
GrammerJoo@reddit
Maybe, but take a look around. How often is even relatively simple concepts in our industry misunderstood or misused? Monoliths vs micro services, agile, event driven, TTD, and so on. I see these things being misinterpreted a lot, and I think it's because people are unwilling to learn, or they start with their own assumptions and then try to fit the buzz words into their agenda.
Venthe@reddit
This will be an honest question - what has the inertia to do with the infrastructure/ec2/load balancer?
DDD is ultimately about the bound contexts, domains and the ownership of the invariants. I fail to see how that might have any impact on what you've wrote -- except if the "DDD guy" read the first part of the blue book only, and tried to introduce every structural pattern (plus ports-and-adapters) for a good measure. Still, this has liitle to do with DDD.
EverythingsBroken82@reddit
all the guys who i knew talking about DDD and co were more interested in having the super-est codebase instead of actually getting the job done... it would be much cooler to discuss if some pattern or domain separation was done correctly. one could discuss philosophy SO MUCH.
recaffeinated@reddit
Junior engineer?
At some point in your career you realise that the hard part in software engineering is organisation; where you put code and how those pieces relate to each other is the toughest problem to solve, and if you get it wrong at design time its the hardest to change.
EverythingsBroken82@reddit
sadly, no, they were not junior engineers.
Heffree@reddit
Having structure and guidelines typically helps you get the job done faster and more accurately. Or if not this job, the next one then.
EverythingsBroken82@reddit
that can indeed be the case. But the people i met or worked with concentrated multiple times more on getting "the architecture" perfect than actually delivering. And after a certain degree of accuracy, the client does not care and the return-on-invest is negligible.
And it was not faster for sure then if they would have cared less about it most of the times. and when i suggested it's not worth the time (after that degree of accuracy) i was reprimanded that i have no idea.
they even did it in a resarch project, where they wanted to learn about Azure Architecture.. after 3 sessions when i asked, so when will we actually instantiate a infra structure component i was again told that i have no idea. i changed the project. the research project died without ANY result, not even code to show.
naa, it's just i-am-the-best-architect-rambling, where people make the tool to an identity, a bit like vim/emacs/bash.
smarkman19@reddit
Architecture only helps if it shortens the path to working software. timebox design to a one-pager (context diagram, main entities, failure modes, latency/throughput targets, data ownership) and commit to a walking skeleton by end of week one. Set a depth budget: from the HTTP handler you get max three hops before real work; no interface until there are two real implementations. Keep DDD where the domain is actually gnarly; everywhere else, ship simple CRUD. Run an abstraction amnesty monthly: delete unused layers and factories, collapse over-engineered helpers. Make it measurable: track lead time to first prod request, error budget, on-call pages, and cost; if a pattern doesn’t move those, stop it. To avoid yak-shaving, I’ve used Supabase for auth, Kong for gateway/rate limits, and briefly DreamFactory to expose legacy tables as REST while the core took shape. Ship a thin vertical slice fast, cap complexity, then iterate.
seweso@reddit
Is there even an alternative to this?
Spaghetti?
killergerbah@reddit
I like that the title says 'is a way' and not 'is the only way.' I work on a team that tries to separate different features of the same app into microservices and I think it makes us a lot slower due to having to maintain a lot more infrastructure and protobuf files, and service boundaries making it more difficult to access data or maintain data consistency. Our team is only around 5 engineers. Why NOT just use a monolith sometimes?
gjosifov@reddit
People reading books, blogs and they still misunderstand the words
BCE - boundary control entity is a particular way to structure your app
DDD - a way to build application origin from early 2000s and DDD will over complicate your application if you take every word as gospel
Example
You can build this with code, but it is easier to use the database and CDC tech (depending how much data you have) + apache big data stack
a simple solution is to use (lets say 10-20 MB of report data / month)
triggers + audit tables + read replica database
Regulatory Report will be 1 database view on the read replica database
easy to implement, easy to maintain
But those DDD monks will tell you that isn't a true DDD, because you don't have a class called Compliance Context or AuditLogAggregate
and the truth is "they won't maintain the over-engineering mess, but you will"
whereiswallace@reddit
CDC can only tell you what happened (e.g. a balance changed) but not necessarily why. Was there a payment? Was there an adjustment?
Zardotab@reddit
It's implying microservices by default. Caution! If it's not webscale nor big "enterprise" app, don't microservice up front. Our shop is still recovering from excess microservitus. I suspect Resume Oriented Programming on behalf of the architecture, who fortunately is gone now. Bloatifying jerk!
Our shop tends to start by drafting an ERD. Key actions can then be tied to the entities in it. It's worked well, and is time-tested. Some approaches are too "verb happy" for my tastes. To the dev it's just either data moving or status codes changing, whether it's called a "withdrawal", "transfer", etc. is mostly immaterial to devs. It may affect screen labelling, but that's more of a UI concern.
vips7L@reddit
DDD has nothing to do with microservices.
Plank_With_A_Nail_In@reddit
The end of the article you haven't read uses "microservices" in every single sentence.
Zardotab@reddit
Okay, but the article should clarify that in my opinion, as stated nearby.
vips7L@reddit
It's /r/programming. You should by default assume that all articles posted here are shit.
HarveyDentBeliever@reddit
Which is funny because DDD and "Clean Architecture" are themselves a form of over engineering if they aren't needed.
Venthe@reddit
And they are useful in any non-trivial domain.
You'll not use DDD for CRUD; you'll have limited benefits from the "Clean Architecture" with the ETL system.
But if you have a rich domain? Both deliver.
SV-97@reddit
Whenever someone says "webscale" I immediately think of this gem: Mongo DB Is Web Scale
user0015@reddit
Pepperidge farms remembers.
kaptainlange@reddit
Can you explain what you mean by "it" and if "it" is DDD, how does it imply microservices by default?
Zardotab@reddit
I explained that here. I also removed the word "default" from my statement, as it's admittedly not clear.
lan-shark@reddit
I think he's referring to the article rather than DDD specifically. There's a small note at the bottom of the article that says non-microservice approaches exist, but the article definitely reads as microservice-oriented to me as well. But yes, DDD can definitely be used in other contacts
Valiant_Boss@reddit
It doesn't, you can do DDD without microservices
lan-shark@reddit
Shout out to all those who have more microservices than users. Happens to the best of us
Zardotab@reddit
Watching failures is often a good learning experience, but you'll never get back the lost sleep or hair.
PositiveUse@reddit
It’s not. It’s implying modularization by default. Microservices imply network impact, modularization is not.
KamiKagutsuchi@reddit
There's nothing about DDD that implies micro services. You could put all your bounded contexts within one application, so long as they communicate through well definied interfaces and don't poke around at each others internals. This is easier to enforce if each bounded context is it's own service, but not required.
Zardotab@reddit
Under the section "Where Is It Used", microservices is mentioned multiple times. It doesn't outright say "use them!", but deserves a caveat to avoid the implication in my opinion.
trolleid@reddit (OP)
Thank you for commenting, my ending wasn’t clear I see. I am absolutely NOT advocating for microservices by default. I just mentioned it as an example where DDD is applied. Thanks
sampullman@reddit
DDD has been around for 20 years or so, it's not exactly a fad anymore. I can't say I love it, but as another commenter mentioned it doesn't have to be microservice oriented.
It's also not all or nothing, you can apply the parts of it that make sense for your project, and it's always nice to have the team working with an ubiquitous language.
CallMeKik@reddit
You can do a monolith with this. Fairly easily
TwentyCharactersShor@reddit
You're not thinking of the poor management consultants that need a fresh hype cycle every decade or so to justify their existance and extortionate fees.
And you're right, follow the CRUD and understand your users. We massively overcomplicate things far too often.
bennett-dev@reddit
And thus, through assumptions about "related events", the worst thing to happen to software architecture was conceived.
read_at_own_risk@reddit
Like building a car from a roadmap
CanvasFanatic@reddit
More like building a car with a diagram of how you intend to build the car.
read_at_own_risk@reddit
Explain to me how you get to a gearbox starting from domain events and aggregates.
Venthe@reddit
GearUp Event, GearDown Event (Or RatioChanged) emitted by a Gearbox Aggregate. As long as the contract of the events is maintained, and the Gearbox Aggregate is the sole owner of the gearbox invariants (like the limits on the shifter) then you can implement whatever gearbox you want, with automatic, manual or linear at your leisure.
This is what DDD enables - clear separation of concerns at a domain level.
read_at_own_risk@reddit
You're assuming the conclusion. The domain is about transporting people from one place to another. It consists of roads and locations and regulations and people. Simulating the domain isn't going to produce a car.
A problem with DDD is that it doesn't take into the purpose of the system. Information system, control system, resource planning, simulation, game, etc. Everything is designed like a domain simulation.
Venthe@reddit
Because that's not the responsibility of the domain model. As you are probably aware, DDD deals with the facts about the domain. Facts - be it events, invariants - will be the same regardless of the purpose of the system. Same thing with the bounded context - domain-constrained language will be unchanged regardless of the purpose.
Now it's up to the system designers to take these facts, take the knowledge of a purpose to turn those into an actual model. In short:
No, it won't. But we are not in a business of a car manufacturing, we are in a business of creating a software that is capable of reflecting the car itself. One might say, we are in the business of creating a model of a car.
cfa00@reddit
How would you know the facts defined are complete and capture the domain at hand? Where it might be a fact that wasn't specificed requires changing earlier facts.
Of course the above isn't something unique to DDD it's any "non-clear problem" (idk maybe there is a better way to phrase it). Where you don't have all the facts or can't have all the facts for one reason or another where the problem really becomes figuring out those facts.
concrete example from chatgpt to paint the abstract statement above more concretely: 1. Example: Shipping Domain With an Incomplete Fact Initial Fact (incomplete):
A shipment has one destination address.
So your Aggregate looks like:
Shipment DestinationAddress (value object) Ship() requires it.
Everything works. Requirements seem clear.
Later operations say:
Some shipments can have multiple drop-off stops on the same delivery route (multi-stop shipments).
Your previous “fact” wasn’t wrong; it was incomplete. This forces a redesign:
Shipment Destinations: List
You now need invariants like:
stops must be ordered,
max 10 stops,
no duplicates,
route cost recalculated for each stop.
3. Root Cause of the Incompleteness
1. Hidden domain knowledge
Subject-matter experts often omit important rules because they assume you already know them, or they consider them “not relevant yet.”
Your model suffers from unknown unknowns.
Domains aren’t static. Business introduces new capabilities, offerings, or regulations. This is domain evolution.
Initial versions trade detail for speed. Later you hit edges the simple model cannot support.
Sometimes a domain expert reveals a rule only when a concrete scenario triggers it.
Example: “Oh, a shipment can’t go to the same city twice unless the second stop is a warehouse… that’s always been the rule.”
Compliance rules, partner integrations, or environmental constraints change the shape of your domain.
DDD encourages:
ubiquitous language continuous learning domain expert collaboration iterative model refinement
…but no domain is fully knowable upfront. You discover truths only when real workflows hit constraints or contradictions.
This is why DDD treats the model as a living artifact, not a fixed schema.
Venthe@reddit
I did not imply that, at any point.
Still, you model with the known facts; then you redesign. I believe this is obvious; as trying to treat the model as "there will always be gaps" would lead us to nowhere.
cfa00@reddit
Did I imply that you did imply that? If so then that's my bad. I was just curious what you answer would be.
Understood, so no why to verify ahead of time or make some assumptions within initial modeling that if so and so chamges this model won't hold.
read_at_own_risk@reddit
You talk about modeling facts but the article shows a domain implemented as classes. OOP is NOT a data modeling discipline, despite its superficial similarity to the old network data model. My point with the car example is that the problem space/domain can be very different from the solution space/system design.
CanvasFanatic@reddit
The domain events and aggregates tell you where to hook the gearbox up to the rest of the car and how to make sure there’s room for it.
kreetikal@reddit
DDD isn't real.
golgol12@reddit
I look at this and think, how slow do I want this to run?
Why return an error when you can just throw an error?
ReddiDibbles@reddit
If you looked at that example and thought the throwing of an exception was in any way important to the point being made, you need to work on your reading comprehension, like A LOT.
VirtualMemory9196@reddit
It’s more about the design methodology then the design itself.