This post is a part of the series:
As it turns out, very few people are familiar with a Domain Driven Design (DDD). Eric Young described this approach, and Vaughn Vernon explained it.
I highly recommend reading their books on the subject.
The main idea of DDD for me is to have a close collaboration between Software Engineers and Domain experts, so software created will reflect the mental model of the people who will use it.
Another aspect which I like is a focus on finding good boundaries within the system which keeps parts small and maintainable.
My goal is not to teach you DDD in one post but to give you a minimum understanding of the concept so we can move on to the Event Storming workshop.
The subject area where the software will be applied to solve the problem.
An abstraction of the domain.
Note: one of the vital components of DDD is that the domain model is constantly changing due to the expansion of the domain and continuous learning the domain nuances.
Set of terms and concepts ubiquitous in the domain. It is the language Domain experts use every day.
The goal of the Software Engineering team is to learn it and use to understand the domain better.
Learning usually happens through domain modeling.
Part of the domain where the specific term means one exact thing.
A classic example would be an e-commerce application: product in the shipping context will have some size and packaging information, while the cart context we are interested in price, for example.
Another brilliant example:
Part of the domain. Part of the problem space.
Often has a 1to1 relationship with the bounded context, but it is not a requirement.
Types of subdomains
Part of the system, which your business knows the best, and it is the sole purpose of your business to excel here.
Subdomain which is important, but does not give you a competitive edge. So different tactics might be applied to implement it.
Example: if you are e-commerce business, product catalog and cart might be vital to you, but the shipping you might decide to outsource to another provider. Hence shipping subdomain is a Supporting.
Note: over time, you might consider to shift your business model and make Shipping your core domain.
Subdomain which performs some generic role yet required role. The best example is the Authentication and Authorization domain, which is needed, but most of the time "buy vs build" decision is better here.
An object that is defined by its identity and not by its attributes.
An object which is primarily defined by its attributes and does not have an identity.
Example: Address of the person
Collection of objects that all bound to a single root entity. Root entity, in turn, guarantees transactional consistency of the aggregate. It defines a transactional boundary. Should be modeled to have a reasonably slow size.
Event important to the domain experts
If you hooked by this short description, I encourage you to read books by Eric Young and Vaughn Vernon. And watch a few videos or training.