Domain-Driven Design

DDD webinar.

Transcript

1. Ivan Paulovich @ivanpaulovich Stockholm, 2020 Nov 3rd Domain-Driven Design
2. @ivanpaulovich
3. Introduction Strategic Design: High Level Design People Interactions Business and Dev Collaboration Tactical Design: Low Level Design Source Code Building Blocks in Code
4. Strategic Design • Bounded Contexts: it is the conceptual boundary where terms are unambiguous. • Context Maps: the di f f erent kinds of relationships between Bounded Contexts. • Ubiquitous Language: shared language build by business and development and is expressed in the domain model. @ivanpaulovich
5. Sales Bounded Context Customer Sales Person Product Support Bounded Context Customer Ticket Product Defect Bounded Contexts
6. Strategic Design • Context Maps • Shared Kernel • Partner • Anti Corruption Layer • Customer / Supplier • Conformist @ivanpaulovich Sales Bounded Context Customer Bounded Context Context Map Upstream Downstream
7. Strategic Design • Context Maps • Shared Kernel • Partner • Anti Corruption Layer • Customer / Supplier • Conformist @ivanpaulovich • Shared Kernel requires more collaboration between peers. • Conformist has no collaboration at all. • Anti Corruption Layer builds a fence between the dependencies.
8. Strategic Design • Context Maps • Shared Kernel • Partner • Anti Corruption Layer • Customer / Supplier • Conformist @ivanpaulovich • Shared Kernel boundaries are very light in comparison to Anti Corruption Layer mapping.
9. “Why don’t you just make the boundaries right from the beginning?” @ivanpaulovich
10. DDD is About Learning @ivanpaulovich You can’t just draw all the “boundaries” up front. — It will cost you a lot! Bounded Contexts are owned by “one team” that builds its language. Focus on important and core business. Don’t make complex things more complicated than needed.
11. Tactical Design • Design Patterns and Building Blocks applied within a Bounded Context. • Used to enrich the Domain Model. • It is low level design and hands-on.
 • It is the opposite of Anaemic Model! @ivanpaulovich
12. A Wallet Application Deposit Withdraw Transfer Close Account Open Account Database Persistence Exchange Service User Interface Exchange Rates API In Memory SQL In Memory Security @ivanpaulovich
13. Domain-Driven Design Patterns • Bounded Context • Value Object • Entity • Aggregate Root • Repository
 • Use Case • Entity Factory • Domain Service • Application Service @ivanpaulovich https://github.com/ivanpaulovich/clean-architecture-manga/wiki
14. Virtual Wallet Customer Checking Account Credit Debit Aggregate Root Entity Value Object @ivanpaulovich
15. Virtual Wallet Customer Checking Account Credit Debit Aggregate Root Entity Value Object @ivanpaulovich Account Balance Bounded Context
16. Virtual Wallet Customer Checking Account Credit Debit Openning Date Amount Transaction 
 Date Description Amount Transaction 
 Date Description Name Personnummer Mobile Phone 
 Number Aggregate Root Entity Value Object @ivanpaulovich
17. Virtual Wallet Customer Checking Account Credit Debit Openning Date Amount Transaction 
 Date Description Amount Transaction 
 Date Description Name Personnummer Mobile Phone 
 Number Aggregate Root Entity Value Object @ivanpaulovich Customer Bounded Context Balance Bounded Context
18. A little bit of code…
19. Entity @ivanpaulovich 1. Highly abstract. 2. Mutable. 3. Uniquely identi f i ed by an ID
 (inside the aggregate).
20. Value Object @ivanpaulovich 1. Encapsulate tiny business rules. 2. Immutable object. 3. Uniquely identi f i ed by comparison
 of its properties.
21. Aggregate Root 1. Owns the entities objects graph. 2. Ensures the state consistency of 
 children entities. 3. De f i nes the consistency boundary. 4. Highly Abstract. 5. Highly Stable. @ivanpaulovich
22. Working with Aggregates Aggregate Entity Value Object Value Object Entity Value Object Aggregate • Aggregates know each other only by their IDs. • Keep a low coupling between them. @ivanpaulovich
23. Repository @ivanpaulovich 1. Provides persistence capabilities to Aggregate Roots. 2. A Repository for every Entity is a code smell.
24. Use Case • It an application entry point. • Shows the usage. @ivanpaulovich
25. @ivanpaulovich