🔴 Stream: DDD Context Mapping with Clean Architecture

Thursday's Agenda, Recap of last week

We’re moving to the Strategic aspects of DDD: Context Mapping! How does it benefit us, what does the conversation look like? How do we connect the dots with Clean Architecture and Microservices?

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

• What is context mapping?

• Domain-centric architecture

• DDD mapping to Clean Architecture microservices

• Q&A, Live Discussion

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

Special live guest:

John Gallagher

Fundamentals of Domain-Driven Design

💡Domain-driven design (DDD) is a holistic and refactoring-focused style of design that is driven by what the code is telling you, rather than being prescriptive.

💡Many developers focus on implementing the tactical patterns of Domain-Driven Design without fully understanding the more important concepts like bounded context and aggregate roots.

🙋🏼‍♂️John: “What is a good example of an Aggregate to explain to someone?”

🤔 Denis: “Imagine an invoice with line items and you have to enforce a business rule that says ‘you can only have 3 line items and 1 discount. But you must have a line item to have a discount.’ Figure out the minimum event/state data needed to enforce this invariant rule and encapsulate it. The result of the encapsulation is an Aggregate.“

😍 "I absolutely love the idea of getting beyond the technology and into the meat of the actual problem that we're dealing with here."

🧩 Event modeling is a better approach for capturing domain-driven design than event storming, as it eliminates unnecessary technical jargon and allows for easier communication with business stakeholders.

💡 Domain-driven design is not about creating the perfect system, but about continuously modeling and adapting to find and solve problems.

🏦 By treating transactions and account events as value objects and domain events, the design of the system can be improved, allowing for better communication and handling of successful and failed transactions.

Object-Oriented Design Principles and Techniques

💡The use of value objects in domain-driven design is important for modeling complex domains and ensuring that the design is business-centric rather than database-centric.

🤔 Encapsulation is a fundamental principle of object-oriented design, and it includes hiding the details to maintain abstraction.

💡Coupling to the signature of a value object rather than its data is the essence of object-oriented design and allows for ultimate flexibility in swapping out different components.

🤔 Understanding and implementing dependency inversion can lead to significant improvements in code organization and reduction of duplication.

Importance of Aggregates and Repositories

🤔 Enforcing complex invariants, such as limiting the number of relationships in a database, can be difficult without the use of aggregates in domain-driven design.

💡 The repository's role is to provide infrastructure-level consistency, ensuring atomic operations and synchronization with replicas, while the aggregate enforces business-level invariants and rules.

💭 Repositories in domain-driven design solve the problem of storing everything in memory by defining aggregates that determine the minimum amount of data needed to enforce domain rules, avoiding the need to bring the entire database into memory.

💡Aggregates enforce business rules in memory in a way that databases and other technologies cannot.