domain-driven-designload-balancingnservicebuscqrs

Domain driven design concepts and relation with CQRS


I recently started to become familiar with DDD concepts and CQRS and I realized that one of the most important concepts in CQRS is DDD beside load balancing, NServiceBus and etc but I am curious if we can use DDD concept alone without using it in CQRS complexity for developing and creating our project. As I know it is an approach to software development for complex needs by connecting the implementation to an evolving model.I need to know that how much should be the scale of project to use DDD alone or with CQRS.


Solution

  • As a complement of @expandable's answer:

    CQRS, aggregates, event sourcing, etc. are just tools. Experience shown that they work well in DDD projects. Using these tools does not mean that you do DDD.

    DDD is about distilling an ubiquitous language through conversations between developers and domain experts. During these discussions, you will notice that some word have different meaning depending of the context.

    For instance, you can think about the life cycle of a product for an online retail store (like Amazon). After the discussion with the domain experts you may find that the Product have a different meaning depending on the life cycle of the purchase. For the retail context, a product is about price and description whereas in the shipping context what matters is the destination address and the size and weight of the product.

    This is a clue that two languages are used and that you probably have to create a bounded context for each (retail and shipping). A bounded context represent an area of the domain in which one language is used. The context boundaries appears when the meaning of the words of the language start to change.

    The bounded contexts identified after the discuss between developers and the domain experts need to be aligned with the code base. For this example, you would probably create a package for retail and another one for shipping. Bounded context implementation is usually quite decoupled one from another. For instance, each bounded context would have it own product class with different properties.

    Each bounded can have it own architecture: CQRS, Event Sourcing, Hexagonal, etc. depending on the needs. However you should be careful that the architecture that you choose is well aligned with the bounded context's domain. For instance, you would probably not use event sourcing if your domain is not event based itself.