Domain-Driven Design

If you are doing CRUD in DDD ... "You are doing it wrong"

Right, communicating to the business is actually the core message of DDD. It should potentially be called “anthropological design” since the “domain experts” are a synonym for your non-technical users of your software (the domain is the business domain, which is whatever your software is trying to do for them). The message is that you have to observe your users in their natural habitat.

Let me put it this way, when Twitter started out, they did not have tweets. They had posts, and the act of posting to Twitter was called twittering. They were not associated with birds (actually more with whales lol). The idea of birds and tweeting actually came later with a third-party client interacting with their API.

Eric Evans in the early aughts now makes a big splash with this outrageous statement, where many of us graybeards would instead say “if it ain't broke don't fix it”: Eric Evans would recommend that the posts table in the database be renamed to the tweets table. Version 2 of the API should not reference “posts” or post_ids, but rather tweets and tweet_ids.

Why?! Those sorts of migrations are painful and clumsy! Yes, Eric says. (He is not stupid.) Maybe it's a lost cause. But, Eric remarks on two things:

1. There is no reason to believe, given software’s previous performance, that any amount of upfront planning is going to generate the most consistent useful model before the software is built and we can interact with it. So you're going to want to iterate. What are the systematic obstacles to renaming the table and the API, and can we overcome them so that we can do lots of little experiments?

2. Something else that is clumsy and painful, is when your users come to you reporting a problem with Widgets or whatever, and you go off and you fix the FactoryService to add some new functionality to widgets, tell the user that their problem is fixed, and they go and do the thing again and run into the same problem that they ran into, “it's not fixed yet!”. Why did this happen? One big reason is that the word “widget” means something different in the database versus the backend, or in the backend versus the frontend, or in the frontend versus the real world. Twitter might get some other notion of “topics” and they roll it out and everyone starts to call them “posts”, now the topic table holds posts and the posts table holds tweets, and you're always looking for “posts” in the wrong table now.

So, you should rename the table because first, this should be a possible thing for you to do and building up that sort of leverage is going to pay dividends later, and second, the less friction we can have by transforming the way we developers speak into the way that our users speak, is going to pay dividends too.

This anthropology is kind of the core part of DDD, I don't understand why people try to do DDD as design patterns rather than saying that it's the users who unwittingly dictate the design, as we redesign around them to reduce friction.

It's similar to, I don't understand why people find it hard to draw context boundaries in DDD. So bounded contexts are a programming idea, in programming we call them namespaces, they exist to disambiguate between two names that are otherwise the same. DDD says that we need to do this because different parts of the business will use the same word to refer to different things, and trying to get either side of the business to use some different word is error-prone and a losing proposition. So instead we need namespaces, so that both of our domain experts can speak in their own language and we can understand them both because in this context we use this namespace, in that context we use that namespace. So: where do you draw the boundary? In other words how big should your modules be? (Or these days, for “module” read “microservice”.)

Simple: you partition users into groups, based on the sorts of things that they seem to care about when they are interacting with the system, and the different ways that they talk about the world. The bounded context is not an “entity” or a “strong entity” or a service-discovery threshold, rather it is an anthropological construct just like everything else in DDD. “The people in shipping care about this for one reason, the people in billing care about it for another, they don't usually talk to each other, but I guess sometimes they do...” sounds like you've got a shipping module/microservice and a billing module/microservice. The boundary is the human boundary.

Similarly for “should I use events or RPC?” ... Does someone from shipping ever come up to the billing department and say “The delivery costs a ton more because XYZ, the customer said they preferred to pay more rather than cancel the order, I am gonna stay here in billing until this critical task is complete,” or whatever, or would they prefer an asynchronous process like email, “we will just put it on the shelf until we can pay to safely ship it.” Different industries would have different standards here! If it's something that has no shelf life, that delivery does not want to keep in the shelves for one second longer than it has to, then that drives the different behavior. Only way you can know is by observing your users in their natural habitat.

How exactly does DDD advocate forming bounded contexts?

I ask because only ever heard personal opinions in answer to this question. I researched it heavily and found nothing. As far as I can tell it doesnt.

Yet another overloaded tech buzzword. For me, DDD means 2 things:

1. Listen to how your customer refers to their business and internalize this perspective as if your life depends on it (your career certainly may).

2. Find a way to build your product and communicate about it in similar terms. The methodology should be understood to be domain-specific.

Anything that extends the philosophy beyond these points is making assumptions about your product that really only you and your customers should be making.

The only concrete technical assumption I would make here is that you probably want to at least consider SQL for a few minutes if you are dealing with tons of distinct types and complex, rapidly-changing requirements from the business. If you can find a way to make the business write their own logic/queries in a language they understand, you have discovered the most powerful force multiplier I am personally aware of right now.

Perhaps the problem is inventing a new language for good application design. Uncharitably, this explanation sounds as if you've taken a description of modularity, type-safety, and maintainability and run it through a randomizing jargon thesaurus.

If an experienced developer can barely understand you, there's a communication problem.