Introductory presentation about Domain Driven Design

1. ● Chcesz pracować w LAB?
Pisz śmiało!
● Chcesz zrobić swoje zadanie
rozwojowe we współpracy z
LAB?
Pisz śmiało!
● Masz propozycję tematu, który
mógłby zostać rozpoznany
przez LAB?
Pisz śmiało!

2. Wojtek Suwała, ASC LAB Head Architect
Domain Driven Design
Introduction for the Software House

3. Software development is
easy,
isn’t it?

4. We must be doing something wrong ...
We are developing software since 1960’s, yet:
• From 2011 to 2015 the percentage of successful IT
projects remains unchanged on a level of just 22%
• Over 19% of all projects failed
• The rest have experienced challenges
https://www.projectsmart.co.uk/white-papers/chaos-report.pdf

5. Complexity

6. Good complexity :)
Domain logic complexity inherent to the domain itself.
Bad complexity :(
Accidental complexity from:
• mixing problem space with solution space
• lack of understanding of business domain
• mixing technical solution complexities

7. Mixing domain complexity with technical
complexity

8. Enterprise Software
Development
Best Practices

9. Developers
Business

12. Domain-Driven Design is a language and
domain-centric approach to software
design for complex problem domains.
The term was coined by Eric Evans in his
Complexity from the
domain is inherent
seminal book “Domain-Driven Design:
Tackling Complexity in the Heart of
Software”. It consists of a collection of
patterns, principles and practices that will
enable teams to focus on what is core to
the success of the business while crafting
software that manages complexity in both
the technical and business spaces.
How about doing it right

13. What do you mean when you say Software
Development?
Software development is a collaborative
learning process involving developers
and business experts.

14. Problem Space
• Understanding customer’s business domain
• Building shared language
• What is our customer’s core business?
• What are customer’s goals?
• What problems we are trying to solve?
• Where our customer can gain / lose money?

15. Big Picture Event Storming

16. Domain Storytelling

17. Big Picture Exploration Outcomes:
• Better understanding of business domain
• Initial business concepts definitions
• Hot spots and opportunities revealed
• Big Domain initially divided into smaller parts - subdomains

18. Not All Parts Of The Problem Are Equal

19. Subdomains

20. Subdomain types
Core domain - the core thing identifies customer’s business
and distinguished them from competitors. This is where we
should focus on and where we can send our best troops.
Supporting domains - things that must be done in order to
support core business but are not unique. No need to spend
lot of time modelling it. Probably existing patterns can be
used. Less skilled teams can be assigned.
Generic domains - things most enterprises do in the same
way. Can be bought/outsourced.

21. Supporting / generic subdomains

22. Subdomains - Finding Core
Agile Estimation can be used to identify Core and where we
should apply DDD tactical patterns versus CRUD.
On the other side, there is the Complexity/Cost that is
associated with implementing software to manage the
Bounded Context.
Subdomains with Large Competitive Advantage and Large
Complexity/Cost are the ones we should focus our effort on.
Alternatively use Impact Mapping.

23. Solution Space
Defining right solution to the right problem with a little help
of …
• Bounded Contexts
• Models
• Ubiquitous Language
• Context Maps

24. Corporate Model Anti-Pattern
Developers and Analysts are often trying to create one big
model that has all data and handles all the use cases.
We try to “sum up” many people different views on given
term.
This approach leads to having brittle, complex models full of
unnecessary abstractions. It brings lots of accidental
complexity to our solution.
Such model is hard to extend and maintain over time.
It is makes dividing work and responsibility to teams very
hard.

25. Don’t put everything into one model
Policy
Create Offer, Buy Policy
Annex, Terminate
Register Case
Approve Case Payment
Register Payment
Change Payment Schedule
Create Renewal Offer, Renew
Calculate Reserves
Calculate Commission
Renewals
Claims
handling
Payments
Accounting
&
Reporting
Sales
Policy
Management

26. Don’t put everything into one model
pictures from https://refactoring.guru/smells/large-class

27. Bounded Context & Ubiquitous Language
Bounded contexts divide solution space into smaller parts where we
work on smaller models.
Bounded context defines applicability of the model. It gives clarity on
what is model used for, where is should be consistent and what it
should ignore.
Bounded context protects model inside it from things outside of it.
Model should only change to better support functionality it is designed
for, not due to requirements external to it.
Bounded context gives team assigned to it autonomy and protection.

28. Bounded Context & Ubiquitous Language
Given domain term has precise meaning in given context.
Project language shared between devs and customer and
reflected in code must be precise in given bounded context.

29. Bounded Context & Ubiquitous Language
Example: E-Commerce System
Product in context of Sales is described by price, available models,
technical specification.
It exposes two capabilities: can be sold and can be found by various
criteria.
Product in context of Shipping is described in terms of weight,
package size, package handling rules, warehouse location and
stock.
It exposes capabilities: can be found, can be shipped, new stock can
be placed and located.

30. Bounded Context & Ubiquitous Language
Bounded contexts should be created around business
capability, not around data.
Bounded contexts tend to align with customer organization’s
structure - Conway’s Law

32. What is domain model?
Domain model is central part of Domain Driven Design. We
focus on creation and further enhancements of domain
models.
It’s first version comes as analytical model from
collaboration of devs and business experts during design
and knowledge crunching sessions.
It represents view of the domain needed to support
business use case. It is not model of real world.
It needs to evolve iteratively to keep itself useful.
Domain model is expressed in code. Code model is bound to
analytical model through Ubiquitous Language.

33. Domain model
The code is primary expression of the domain model.
You should take care of keeping code and conceptual model
in sync.
If during implementation you need to express new ideas or
change meaning of already defined things, this should also be
reflected in the language you communicate with domain
expert.
The same care must be taken to handle changes coming from
business understanding or requirements changes.

34. Domain model
Patterns, Principles, and Practices of Domain-Driven Design by Scott Millet and Nick Tune

35. How to create a good model
• domain modelling is a team activity
• domain model is not a model of a real life
• model only what is relevant
• domain models are temporary useful
• be explicit with terminology
• limit your abstractions
• implement model in code early and often
• don’t stop at first good idea
Remember: All models are wrong, but some are useful

36. Event Storming Design Level

37. Event Storming Design Level

38. DDD Modeling Whirlpool

39. Context Maps
Context map define how different bounded contexts are
integrated (how they communicate with each other - at the
system level and at the teams level) and how language of
one context is translated into language of the other.
Context mapping strategies:
Shared Kernel, Customer/Supplier, Conformist,
Anti Corruption Layer, Separate Ways, Open/Host Service,
Published Language, Partnership
Excellent presentation on the subject:
https://speakerdeck.com/mploed/context-maps-an-enhanced-view

40. Aggregate - “clusters” of things tightly related together in
given context. Aggregate takes care of keeping its state
consistent and holding invariants.
Invariant is business rule / characteristic of a thing that state
must be compliant to.
From developers perspective Aggregate is a scope of
transactional processing. All things within aggregate are
saved successfully together or save fails reverting state to the
original one.
Aggregate Root - main element of aggregate, all access to
aggregate is performed only through the aggregate root.
Key Tactical Patterns - Aggregate

41. Aggregates - Example: Online Actions Bounded Context
Auction
Winning
Bid
Bid
MemberAuction
Item
Payment
Method
Category
Shipping
Method
Seller
Question
Answer

42. Aggregates - Example: Online Actions Bounded Context
Auction
Winning
Bid
Bid
MemberAuction
Item
Payment
Method
Category
Shipping
Method
Seller
Question
Answer

43. Good aggregate design rules
• design around domain invariants, keep inside only data that is
needed to hold invariants while supporting operations
• reference things outside only by ID
• favour small aggregates
• large aggregates degrade performance
• large aggregates are potential source of concurrent access
issues
• ignore user interface influences
• avoid dumb collections and containers
• don’t focus on HAS-A relationship, your data model is not
your aggregate model
• do not model real life, only your use case

44. Key Tactical Patterns - Domain Events
Domain Event - fact that describes something that happened
in your domain, something with business meaning.
Domain events are a tool that allows us to have
communication between aggregates.
Domain events live inside bounded context.
One aggregate subscribes to events of other aggregate and
adjust its state.
Application may subscribe to domain events to perform
technical actions: like e-mail sending.
Domain Events can contain references to domain objects in
scope of Bounded Context.

45. Key Tactical Patterns - Domain Events
There is also a completely different kind of Domain Events.
External Domain Events - that are used to communicate
between bounded context. This kind needs different
approach. Such events must be versioned and cannot carry
domain objects.

46. Tactical Patterns / DDD Design Building Blocks
Entities
Value Objects
Repositories
Domain Services / Policies
Specifications
Factories
Application Service / Command Handlers

47. DDD & Architecture
Popular architectures often used when doing DDD:
Onion Architecture
Ports and Adapters
CQRS
… any many many others
but remember
DDD is not architecture

48. DDD & Architecture: Onion

49. DDD & Architecture: Ports & Adapter (Hexagonal)

50. DDD & Architecture: CQRS

51. DDD Misconceptions
• DDD is technical thing
• DDD is about Entities, Value Objects, Repositories
• DDD requires usage of ORM, Spring, ...
• DDD is a framework
• DDD is architecture

52. DDD things to remember
DDD is great for:
- divide important stuff from less important :)
- focus on small but important part
- build shared language of the project that is used for
communication between devs and business
- build models through iterative collaboration with domain
experts
- move shared language from discussion and modelling
sessions into code

53. 53
altkomsoftware.pl
github.com/asc-lab
@AltkomSC
asc-lab@altkom.pl