This week: Tactical DDD Patterns

Thursday's Agenda, Recap of last week

We’re going to get our hands dirty on this week’s stream. Looking into common traps that disrupt adoption of DDD patterns, exploring nuance on aggregates the influence it may have on domain events and testing.

Call for feedback - How are you liking the chat participation on Linkedin? Is the Event for each week easy to find? Do you get value from the recaps?

👇 Sign up on the LinkedIn event to have it easily pop into your calendar. It’s recorded, and also available on YouTube.

Agenda for the Live Stream

• Clean architecture, separation of concerns, encapsulation & data hiding

• Exploring this blog post

• Tactical Patterns: Entities, Aggregates and testing your DB mess

• Q&A, Live Discussion

No worries if you missed it, here’s last week’s recap

📿 Interconnected with Clean Architecture and Event Modeling. EM models the way the data flows through your domain. CA allows you to shape the structure how the dependencies happen. DDD provides a framework of communication that helps the team understand the problem space and processes we are trying to improve with tech.

🧐 Many practitioners who claim to apply DDD, don’t or do so partially. The majority of the surveyed engineers use some part of the tactical aspects of DDD but very few go into the deep details and benefits of Domain-Driven Design concepts.

🚖 The domain of Uber is about getting people from A to B, being a cheap taxi, and providing reliable service. Technology and software being a means to enable that, rather than the main focus.

🔄 Context mapping in Domain-driven Design helps identify shared responsibilities and differences between different contexts, especially even when using the same terminology with different meanings.

🗺 The strategic processes of DDD help you name things, and avoid having overly technical CamelCaseAbstractFactory nouns in your codebase. Coming back to the conversation “How does the business call this?” rather than tunnel-visioning on the coding experience and engineering patterns.

🧠 The point of DDD processes like Event Storming is to establish a framework of gathering requirements so that you can extract the domain from the experts and gathered requirements in order for the entire team to understand them.

🗣 The ubiquitous language enables noun-verb pairings to be discovered and used naturally to match the business and engineering ends of the domain. This allows the team to go into the appropriate level of detail when necessary. When detail is lacking, it helps find gaps in understanding.

💡DDD emphasizes the importance of capturing important events and persisting metadata with the event, allowing for a more comprehensive understanding of the data. Essential when your business has unique needs and is solving a problem that cannot be solved with off-the-shelf solutions.

💡The concept of Aggregates in Domain-driven Design allows for flexible modeling of data, where one row in a table can map to several classes, with one class serving as the main aggregate root or when dealing with complex transactional associations.