Slide 1

Slide 1 text

Ivan Paulovich @ivanpaulovich Stockholm, 2020 Nov 3rd Domain-Driven Design

Slide 2

Slide 2 text

@ivanpaulovich

Slide 3

Slide 3 text

Introduction Strategic Design: High Level Design People Interactions Business and Dev Collaboration Tactical Design: Low Level Design Source Code Building Blocks in Code

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

Sales Bounded Context Customer Sales Person Product Support Bounded Context Customer Ticket Product Defect Bounded Contexts

Slide 6

Slide 6 text

Strategic Design • Context Maps • Shared Kernel • Partner • Anti Corruption Layer • Customer / Supplier • Conformist @ivanpaulovich Sales Bounded Context Customer Bounded Context Context Map Upstream Downstream

Slide 7

Slide 7 text

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.

Slide 8

Slide 8 text

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.

Slide 9

Slide 9 text

“Why don’t you just make the boundaries right from the beginning?” @ivanpaulovich

Slide 10

Slide 10 text

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.

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

Virtual Wallet Customer Checking Account Credit Debit Aggregate Root Entity Value Object @ivanpaulovich

Slide 15

Slide 15 text

Virtual Wallet Customer Checking Account Credit Debit Aggregate Root Entity Value Object @ivanpaulovich Account Balance Bounded Context

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

A little bit of code…

Slide 19

Slide 19 text

Entity @ivanpaulovich 1. Highly abstract. 2. Mutable. 3. Uniquely identi f i ed by an ID
 (inside the aggregate).

Slide 20

Slide 20 text

Value Object @ivanpaulovich 1. Encapsulate tiny business rules. 2. Immutable object. 3. Uniquely identi f i ed by comparison
 of its properties.

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

Repository @ivanpaulovich 1. Provides persistence capabilities to Aggregate Roots. 2. A Repository for every Entity is a code smell.

Slide 24

Slide 24 text

Use Case • It an application entry point. • Shows the usage. @ivanpaulovich

Slide 25

Slide 25 text

@ivanpaulovich