Modeling and Key Patterns of DDD
Explore Domain-Driven Design modeling and key patterns to collaborate with domain experts and define bounded contexts in event-driven architecture. Understand how to break down complex domains, create relevant models, and apply context mapping to integrate them effectively in Golang applications.
We'll cover the following...
Modeling
The domain model is a product of the collaboration between domain experts and developers using the UL. What goes into the model should be limited to the data and behaviors that are relevant to the problem domain, not everything possible in an attempt at modeling reality. The point of a domain model is to solve problems identified in the domain.
Eric Evans suggests experimenting with several models and not getting stuck too long on minutia. We are trying to determine what is important from the conversation with the domain experts. Listen for connecting words to identity processes and behaviors, titles, and positions to identify actors, and, of course, the names of things to identify data. This should be captured on a large surface, such as a whiteboard, a large roll of paper, or a blank wall if we’re doing EventStorming.
The model should be free of technical complexities or concerns, such as mentioning any databases or inter-process communication methods, and should only focus on the problem domain.
Defining boundaries
Every model belongs to a bounded context, which is a component of the application. Because the model belongs to this context, care needs to be taken ...