🔴 Special Guest: Milan Jovanović on Live #9—Hands-on DDD Examples in C#

Thursday's Agenda, Recap of last week

Last call on the TDD survey - The survey is closing end-of-month.

---

👇 Note: Starting 30 minutes sooner this week, at 16:00 CEST. Sign up on the LinkedIn event to have it easily pop into your calendar. It will be recorded, but I suggest you join in live for the chat participation.

Please set an intention if you don’t want to miss it. Let us know you’re coming and put it on your calendar.

Agenda for the Live Stream

• Reviewing Milan's DDD Kata codebase

• Discussing Aggregates

• Insight into modern .NET frameworks and libraries and their overlap with pure DDD

If you missed it, here’s last week’s recap

Collaboration and Communication Skills for Engineers

💡 A team can be partitioned accidentally in a way that makes communication difficult. Learn how to build bridges and intuition about when conversations need to happen to build more knowledge.

🧠 The course on Domain-driven Design Software Architecture by Allen Holub is highly recommended and provides a comprehensive understanding of important event storming conversation in a product engineering context with domain experts.

💡 Even if you lack technical knowledge, asking questions and seeking different perspectives can lead to better solutions. It's important to acknowledge that there may be gaps in our understanding and be open to learning from others. DDD is about talking to humans, the tactical patterns are a small bonus.

Importance of Understanding the Product Domain

🤔 Understanding the problem domain is crucial for engineers, as it involves knowing how users interact with the product and the various aspects of the domain. These interactions shape the basis for what behavior a system exposes. Behaviors, when documented, shape the basis for high-quality automated testing and API design.

5 Whys: Ask questions to uncover the root cause details about certain features. Some examples of the question-side:

• Why are we building this? …

• … why is that necessary?

• … why are we building this ourselves?

• … why is now the right time?

• … why is this the best solutions?

💡 Understanding the behavior of a product is more important than understanding its implementation when it comes to writing tests and adding features. The data representation of the product domain determines if you need to make any tradeoffs or transformations during implementation.

🔄 Agile and scrum methodologies prioritise real feedback from the system during implementation, rather than excessive upfront planning, to uncover and address the most challenging and unknown issues sooner.

🤔 Be open to the idea of throwing away a significant portion of their work if it means improving the overall architecture and platform of the project.