Menu
It is often said that DDD (Domain-driven Design) is better suited for complex domains instead of simpler ones.
What characterizes a complex domain? (please be more specific than "it has complex business rules");
Which are examples of complex domains?
How can I classify a domain as complex (i.e. suitable for DDD) or not?
740
Domain-Driven Design(DDD) is a collection of principles and patterns that help developers craft elegant object systems. Properly applied it can lead to software abstractions called domain models. These models encapsulate complex business logic, closing the gap between business reality and code.
Domain-driven design (DDD) is a software development philosophy centered around the domain, or sphere of knowledge, of those that use it. The approach enables the development of software that is focused on the complex requirements of those that need it and doesn't waste effort on anything unneeded.
DDD refers to the application's problem space - the business - as the domain. A domain is consists of multiple subdomains. Each subdomain corresponds to a different part of the business. Subdomains can be classified as follows: Core - key differentiator for the business and the most valuable part of the application.
Entities are Domain concepts that have a unique identity in the problem domain. Entities represent domain objects and are primarily defined by their identity, continuity, and persistence over time, and not only by the attributes that comprise them.
From my experience 3 most important thing that makes your domain complex:
Size
Big domains tends to increase complexity. Handling and coordinate a lot of things is always hard.
Rules and invariants
Domains (even domains with just a couple of bounded context) might have a lot of domain rules and invariants and/or a lot of nuances in its use cases and process. This increase complexity. Rules that spam a lot of changes in a entity or inter-domains events are often the complex business rules.
Context
Context complexity is hard to explain wihtout a example. Let's put in the table a context complexity related to a entity named Product.
Depending of context; a entity could means different things in your domain. A Product entity doesn't means the same for Factory context, Marketing context, Sales context, PostSales support context, etc.
If the data, user cases, process, behaviour, etc related to Product entity, in every context, are very different the complexity increase a lot even when you just have a handful of context and entities. This usually means that you have many Product entities (one in every context) even if all of them are supported by the same persistence store (in case of ER store, the same table/s).
107
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
