Domain Driven Design (DDD) is a particular way to structure your app.

[-]

FraTe7@reddit

Do we really need a name (DDD) for this? Feels like selling buzzwords 🤣

[-]

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.

Structure the system according to the business domains, not 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

Nothing else scales to that level without correctness and availability problems

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.

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.)

...which has nothing to do with the deployment unit still.

https://testing.googleblog.com/2017/02/discomfort-as-tool-for-change.html

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

Seems like a strategy for brainstorming a system from scratch.

Or mapping the actual business for the purpose of directing the architecture.

Possibly useful, but ultimately unrelated.

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

Compliance Context:

Audit Log aggregate

Regulatory Report aggregate

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

It's implying microservices by default.

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

don't microservice up front. Our shop is still recovering from excess microservitus.

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

This is an aggregate — a collection of related objects managed as a single unit with its own lifecycle.

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

A problem with DDD is that it doesn't take into account the purpose of the system.

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:

Simulating the domain isn't going to produce a car.

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.

New Discovery That Breaks The Fact

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.

Organization discovers new needs

Domains aren’t static. Business introduces new capabilities, offerings, or regulations. This is domain evolution.

Over-simplification during early modeling

Initial versions trade detail for speed. Later you hit edges the simple model cannot support.

Implicit constraints becoming explicit

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.”

External systems or regulations change

Compliance rules, partner integrations, or environmental constraints change the shape of your domain.

Why This Happens Even Though DDD Tries To Prevent It

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

How would you know the facts defined are complete and capture the domain at hand? (...) This is why DDD treats the model as a living artifact, not a fixed schema.

I did not imply that, at any point.

Your previous “fact” wasn’t wrong; it was incomplete

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

I did not imply that, at any point.

Did I imply that you did imply that? If so then that's my bad. I was just curious what you answer would be.

Still, you model with the known facts; then you redesign.

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.

[-]

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.