Domain Driven Design is a set of (paranoid) rules, to uncouple your business logic from all its dependencies. DDD could be seen as SOLID principles applied one step ahead, focusing on your business domain. DDD is to be used to write maintainable and evolutionary software, isolating your precious domain logic so that the project could still be maintainable in a decade. But in practice, once you have read the literature, DDD is hard to start with coding. In this half-day workshop, we full write a simple, but complete DDD system from scratch. DDD rules will be applied using practical object pascal patterns, coming from years of writing DDD code for real business projects. A safe Test Driven Design approach will be followed. The Open Source mORMot framework will be used as a convenient toolbox, focusing on writing DDD expressive code, in a clean SOA architecture.

1. Practical DDD
Arnaud Bouchez - Synopse
Practical
Domain Driven Design

2. Practical DDD
• Arnaud Bouchez
– Delphi Expert
• Various solutions (from Vatican to gaming industry)
• IoT solution (RSI)
• Real-time Monitoring solution (LiveMon)
– Open Source
• mORMot (SOA ORM MVC framework)
• SynPDF SynMustache SynDB SynCrypto
– Training and consultancy
• Synopse one-man company

3. Practical DDD
Practical Domain-Driven Design
• Domain-Driven Design
• Clean Architecture
• Domain Objects and Services
• Let’s Code

4. Practical DDD
Domain-Driven Design
• Set of paranoid best-practices
to focus on what really matters
for long-term maintaining projects

5. Practical DDD
Domain-Driven Design
• Set of paranoid best-practices
to focus on what really matters
for long-term maintaining projects
A life-time process, for sure

6. Practical DDD
Domain-Driven Design
• You can survive without DDD
http://martinfowler.com/bliki/DesignStaminaHypothesis.html

7. Practical DDD
Domain-Driven Design
• Pre-requisites
– Identified and well-bounded domain
– Access to domain experts
– Skilled team, able to write clean code
– You want your internal team to accumulate
knowledge of the domain

8. Practical DDD
Domain-Driven Design
• Pre-requisites
– Identified and well-bounded domain
– Access to domain experts
– Skilled team, able to write clean code
– You want your internal team to accumulate
knowledge of the domain
– Some time ahead

9. Practical DDD
Domain-Driven Design
• DDD is HUGE

10. Practical DDD
Domain-Driven Design
• Purpose of this work session
– Share years
of experiment ^W failure ^W hard work
writing mission-critical DDD server code
using Delphi/FPC and mORMot
– Translate rules into recipes
(you may/should find out your own)
– Have fun writing some code with you

11. Practical DDD
Domain-Driven Design
• One rule to rule them all
– DDD is about uncoupling
the core of your business logic

12. Practical DDD
Domain-Driven Design
• One rule to rule them all
– DDD is about uncoupling
the core of your business logic
which is called the Domain

13. Practical DDD
Domain-Driven Design
• One rule to rule them all
– DDD is about uncoupling
the core of your business logic
– Don’t pollute the system architecture
– Don’t pollute the core business code

14. Practical DDD
Domain-Driven Design
• One rule to rule them all
– DDD is about uncoupling
the core of your business logic
– Don’t pollute the system architecture
 Clean Architecture
– Don’t pollute the core business code
 Domain Objects and Services

15. Practical DDD
Clean Architecture
• Clean Architecture
– Switch from classical n-Tier
Presentation – API – Logic – DB
– To an Onion architecture
hosting the Domain as Core

16. Practical DDD
Clean Architecture
• Clean Architecture
– Inject dependencies using Domain contracts
• e.g. Repository service for persistence
interface defined in Domain,
class implemented in Infrastructure
injected in Application layer
(instead of DB-rooted architecture)

17. Practical DDD
Clean Architecture

18. Practical DDD
Domain-Driven Design

19. Practical DDD
Clean Architecture
• Clean Architecture
– Don’t pollute Domain code
• 80% of your code will be in Infrastructure
maybe with some al dente spaghetti copy & pasta
but your Domain code will stay clean
• Check your uses clause
Domain units should never depend on others

20. Practical DDD
Clean Architecture
• Clean Architecture
– Should be seen in source folder
And keep your “dom” folder clean!

21. Practical DDD
Clean Architecture
• Clean Architecture
– Should be seen in source folder
Proposed naming convention is to follow folder name
InfraConferenceRepo in InfraInfraConferenceRepo.pas
DomConferenceTypes in DomDomConferenceTypes.pas

22. Practical DDD
Clean Architecture
• Clean Architecture
– Should be seen in source folder
Proposed naming convention is to follow folder name
Infra.Conference.Repo in InfraInfra.Conference.Repo.pas
Dom.Conference.Types in DomDom.Conference.Types.pas

23. Practical DDD
Clean Architecture
• Naming Convention
e.g. for Conference Domain and Booking project
TestConferenceMain Test Driven Design code
DomConferenceTypes entities, values, aggregates
DomConferenceInterfaces Domain services interfaces
DomConferenceServices Domain implementation
DomConferenceDepend Infra. contract definition
DomConferenceTest Domain tests
InfraConferenceRepository Infra. implementation
ServBookMain Booking Microservice
ServBookWeb MVC Web UI Server

24. Practical DDD
Domain Objects and Services
• Domain is your business core
– Isolate long-term project code
• The code you will care the most
• Where customers (and money) come from
• Be lazy for future years

25. Practical DDD
Domain Objects and Services
• Domain is your business core
– Cleanest OOP/SOLID style possible
• Lots of Plain Old Delphi Objects (PODO) class
• Favor composition over inheritance
• Define services as interface/class
• Define dependencies as interface

26. Practical DDD
Domain Objects and Services
• Domain is your business core
– Ubiquitous Language
• Code naming should follow real-life naming
• Domain experts should be able to read your code
• Strong Typing everywhere: one thing, one type
• Make the implicit explicit
• Don’t pollute your domain code
– e.g. don’t use SQL key, but opaque types (string, variant)
– use only domain classes/types/units

27. Practical DDD
Domain Objects and Services
• Domain is your business core
– Bounded Contexts
• Convenient processing scope in the Domain
• Compose Domain objects for a given context
• Where Aggregates are atomic-like
• Define well-segregated services

28. Practical DDD
Domain Objects and Services

29. Practical DDD
Domain Objects and Services
• Domain is your business core
– Value Objects
• Stateless representation of data (seat in concert)
– Entities
• Tied to a given reality (seat in plane)
– Aggregates
• Huge object, boundary of transaction
– DTOs, Events
• To avoid leaking the domain objects

30. Practical DDD
Domain Objects and Services
• Domain is your business core
– Aggregates consist in Entities
with nested Value Objects
depending on the Bounded Context
• Aggregates are accessed using Repository services
interface defined in Domain, class in Infra or stubbed
• Optionally CQRS dedicated stores
e.g. via read-only Query service

31. Practical DDD
Domain Objects and Services

32. Practical DDD
Domain Objects and Services
• Domain is your business core
– Domain Services
• Objects methods should be basic and stateful
• Define interface, and implement actual class
• To play with the Domain Objects
– Infrastructure Contracts
• Define interface only, to abstract dependencies
• Persistence/Repository, Anti Corruption Layers (ACL)
to legacy code or third-party services

33. Practical DDD
Domain Objects and Services

34. Practical DDD
Domain Objects and Services
• Domain is your business core
– Domain writing is an iterative process
• Modelizing is about forgetting the details
• There is no definitive model,
only models good enough for a given purpose
– Uncoupling is everything
• Don’t start from DB, but from objects
• Could be easily unit-tested
• Helps publishing stable APIs for clients

35. Practical DDD
Domain Objects and Services
• Domain is the Toolbox consumed by APIs
– Application Layer, or API Layer will do injection
• From Infrastructure layer into the Domain
• To orchestrate all (Micro)services
– Domain is logical, not physical
• There is no single “Domain” Microservice
• Domain is used to implement Service(s)
– Main rule: don’t leak your Domain!
• Define dedicated Data Transfer Objects (DTO)

36. Practical DDD
Domain Objects and Services
• Working with existing Legacy code
– Identify “seams” in your code base
and refactor to publish them as interface
• See my last year session ;)
– Those interface will give access to
• Process / logic as Anti Corruption Layers (ACL)
• SQL statements from the Repository service
– Legacy code will be part of the Infrastructure
• Domain code will stay clean

37. Practical DDD
Let’s Code

38. Practical DDD
• mORMot to the rescue
– Don’t reinvent the wheel: we did it for you
– Plumbing is done magically
• Write plain types and interfaces
• The framework will make SOA and ORM work
• Test, log, authentication, settings, daemons
– But it is not RAD – warning: pure code ahead!
Let’s Code

39. Practical DDD
Let’s Code
• Step 01: Skeleton Code
– testTestAll.dpr
Regression tests
– servServBook.dpr
Stand-alone booking service

40. Practical DDD
Let’s Code
• Step 02: Write Domain Code
– domDomConferenceTypes.pas
Domain objects
– domDomConferenceInterfaces.pas
domDomConferenceServices.pas
Domain services definition and implementation
– domDomConferenceDepend.pas
Infrastructure services definition
– domDomConferenceTest.pas
Unit tests (with no infrastructure)

41. Practical DDD
Let’s Code
• Step 03: Write Infrastructure Code
– infraInfraConferenceRepository.pas
Persistence service using ORM
– servServBookMain.pas
Actual booking service
using Domain and ORM Storage

42. Practical DDD
Practical Domain-Driven Design
• PDF and Code available
https://synopse.info/files/ekon21
• Questions?