Seeing a lot of hate for DDD here so let me offer an alternative point of view from someone who advocated for DDD on my team.
When I joined, my team had been building the backend for the first version of our app for about 4 months. I would describe the state of the code base when I joined as an 'Anemic Domain Model' as defined by Martin Fowler
- There was a 'domain model' in the loosest possible sense
- Each model type was just a POJO with raw getters/setters for each field
- Almost all fields were primitives (mostly strings with a few int/doubles/dates)
- All validation code for these types was done in application code and was fragmented throughout the code base
- Internal DB identifiers were fully exposed into the code model
- Internal service types were liberally mixed with external service types
- No notion of aggregate roots - every entity was just accessed ad-hoc
It was a highly unsustainable approach, and one of the first thing I did was attempt to implement strategic DDD in the areas that were the most painful. This included
- Adopting rich value objects to represent domain concepts instead of raw strings
- Enforcing business invariants inside the model classes
- Enriching the domain entities with methods that matched business behavior and performed validation
- Creation of repositories that shifted much of the persistence details out of the application code
- Defining aggregates based on our required access patterns which simplified our data access
- Bounded contexts for our internal domain - mapping external service types to our own internal representation
The result of all this was the creation of a core 'domain model' that captured business behavior expected of our service and most importantly, ended up significantly simplifying the rest of the application code. If DDD makes your app code more complex, you're doing something wrong.
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.
Well I understood it perfectly as in I read it as "modularity, type-safety, and maintainability"...then again I am familiar with DDD and thus understand the ubiquitous language from the original comment...which is kind of one of the main points from DDD ;)
This sounds like another data point of many in this thread that point towards DDD as a philosophy working very well, while enforcing technical techniques advocated for in the book being hit-or-miss.
This makes intuitive sense to me: it’s much easier to define a principle that applies in many situations but much harder to define concrete technical implementations that do.
In your situation it sounds like the multiplier you applied was in pushing your team towards a rich domain. That’s a much more sensible approach than, say, using CQRS everywhere.
When I joined, my team had been building the backend for the first version of our app for about 4 months. I would describe the state of the code base when I joined as an 'Anemic Domain Model' as defined by Martin Fowler
- There was a 'domain model' in the loosest possible sense - Each model type was just a POJO with raw getters/setters for each field - Almost all fields were primitives (mostly strings with a few int/doubles/dates) - All validation code for these types was done in application code and was fragmented throughout the code base - Internal DB identifiers were fully exposed into the code model - Internal service types were liberally mixed with external service types - No notion of aggregate roots - every entity was just accessed ad-hoc
It was a highly unsustainable approach, and one of the first thing I did was attempt to implement strategic DDD in the areas that were the most painful. This included
- Adopting rich value objects to represent domain concepts instead of raw strings - Enforcing business invariants inside the model classes - Enriching the domain entities with methods that matched business behavior and performed validation - Creation of repositories that shifted much of the persistence details out of the application code - Defining aggregates based on our required access patterns which simplified our data access - Bounded contexts for our internal domain - mapping external service types to our own internal representation
The result of all this was the creation of a core 'domain model' that captured business behavior expected of our service and most importantly, ended up significantly simplifying the rest of the application code. If DDD makes your app code more complex, you're doing something wrong.