The first day slides of the Domain Driven Design course that I imparted on Schibsted Spain.
They talk about technical debt, domain modeling, model driven design and SOLID principles.
4. Spoiler
• DDD is not for the perfectionist
• DDD is based on incremental changes (backed by TDD)
5. Spoiler
• DDD is not for the perfectionist
• DDD is based on incremental changes (backed by TDD)
• Those changes must be guided by business requirements
16. Ubiquitous Language
• A set of business words
• Usually nouns and verbs
Agent
Property
Agency
Sell Buy
Ad Contact
17. Bounded Context
• A set of business words that are part of the Ubiquitous Language
for a specific business area
Agent
Property
Agency
Sell Buy
Ad Contact
18. Context Mapping
• A set of business words that are part of the Ubiquitous Language
whose purpose is to share knowledge between Bounded Contexts
Agent
Property
Agency
Sell Buy
Ad Contact
19. Context Mapping
• A set of business words that are part of the Ubiquitous Language
whose purpose is to share knowledge between Bounded Contexts
Agent
Property
Agency
Sell Buy
Ad Contact
Publish
20. Context Mapping
• A set of business words that are part of the Ubiquitous Language
whose purpose is to share knowledge between Bounded Contexts
Ad Opportunity
Contact Property
Search Demand
21. Exercise 1
• Define the Ubiquitous Language of Real Estate
• Define the Bounded Context of Management
• Define the Bounded Context of Classifieds
• Define Context Mappings between Management and Classifieds
22. Tactical DDD
• Based on Model Driven Design
• Design Data & Behavior as Models
• Based on Clean Architecture Concepts
• SOLID (again)
23. Back to the SOLID
• Single Responsibility
• Responsibility is not based on code, but
on abstractions
• A good abstraction is more valuable
than good code
• But a good abstraction leads to better
code!
• Component responsibility evolves
during the project lifecycle
Domain
Layer
24. Back to the SOLID
• Open Closed
• Open for lower level abstractions, closed
to different implementations
• Abstractions backed by other ones
Contact Contact
DAO
Contact Service
Business Logic
Persistence
Business Transaction
25. Back to the SOLID
• Liskov Substitution
• Ability to change different
implementations that expose the same
abstraction
• Constrained by invariants, pre-
conditions and post-conditions
Client Agent Agency
Contactable
Contact
26. Back to the SOLID
• Interface Segregation
• Expose different abstractions with the
same implementation
• Different abstractions != God object
Agent
Contactable Publisher
27. Back to the SOLID
• Dependency Inversion
• Abstractions are backed by other higher-
level abstractions
• An abstraction must not depend directly
or indirectly on itself
Controller
Application Service
Domain Services
Domains
LevelofAbstraction
28. Model Driven Design
• Responsibility is distributed in models
• Models are an accurate representation of a business concept for a
concrete problem
• Models are stateful and logic-aware
• Models are not necessarily objects (but usually defined with them)
32. Model Driven Design
• Everything should be a model (no defined granularity)
• Model interaction backed by services
• Persistence outside models (DAO)
33. Exercise 2
• Model the following user stories:
• As an Agent, I want to create a Property
• As an Agent, I want to publish a Property as an Ad
• As a Client, I want to contact an Agent through an Ad
• As an Agent, I want to unpublish an Ad
• You can use Java, C# or JavaScript for this exercise
34. Model Driven Design
• Properties of a Model:
• A model has invariants
• A model has multiple contracts
• A model is able to interact with other models
• A model is composed by other models
35. Invariants
• An invariant is a set of constraints based on the system state
• You can’t create a user without an email
• You can’t create two properties with the same ID
• Invariant violations must fail-fast
• A model must not exist in the system if its invariants are not full-filled
37. Contracts
• A contract is the definition of the abstraction that the model solves
• User is a contract
• Agent is a contract
• Both can be implemented by any model
38. Model Interaction
• A model needs to interact with the environment, so the system can
work
• A single model is completely useless
39. Model Composition
• Models are composed by other models
• Primitives are not models, but state
• int, String or long are not business objects
• Avoid Primitive Obsession
• A Garbage Collector isn´t a performance problem
42. Domain Driven Design - Domain Layer
• AKA Business Layer
• Split in two components
• Aggregate Roots
• Domain Services
• Depends on Infrastructure
Domain
Service
Aggregate
Root
Infrastructure
Service
43. Domain Driven Design – Aggregate Root
• An Aggregate Root is the central part of data and business integrity
• Handles interaction with other domain objects
• Handles invariants related with other domain objects
• Aggregate Roots are Entities
44. Domain Driven Design – Entity
• An Entity is a business object that can be referred unequivocally by
a unique identifier.
• Entities are property of a Bounded Context
• An entity can’t be found in more than one Bounded Context
• Entities are a composition of Value Objects and business logic
46. Domain Driven Design – Value Object
• A Value Object is a representation of a business value with its own
invariants and business logic
• Value Objects do not have identity
• Value Objects can be composed
• Value Objects must be immutable and shareable
• Value Objects also represent Entities in other Bounded Contexts
48. Domain Driven Design – Domain Services
• Handle business transactions
• Backed by aggregate roots and infrastructure services
• Must be ACID
• Atomic
• Consistent
• Isolated
• Durable
49. Domain Driven Design – Domain Services
• As A Visitor, I want to login
• Must Exist
• Must not be banned
• Must have been
verified
Find Visitor By
Email
• Password must
match
• Update Login Date
Login
• Persists New User
Info
• Notifies other
system players
about the event
Save User
50. Domain Driven Design – Domain Services
• As A Visitor, I want to login
Domain
Service
Aggregate
Root
Infrastructure
Service
52. Domain Driven Design – Infrastructure Services
• Handle data persistence
• Handle data integrity
• Handle system-wide invariants
• Unique Keys
• Sub-domain Invariants
• Communicate with 3rd party systems (like Event Buses, APIs or DBs)
53. Domain Driven Design – Infrastructure Services
• They can be categorized in:
• Domain Wide Infrastructure Services
• Repositories (!= DAOs)
• Event Publishers
• Command Publishers
• System Wide Infrastructure Services
• Marshallers
• Controllers
• Views
54. Domain Driven Design – Infrastructure Services
• Domain Wide Infrastructure Services are very special
• Their contract are part of the domain, not part of the infrastructure
• Repository interfaces are on the ´domain´ package
• They understand part of the domain language but they are not part of the
domain
• They must validate some invariants
• The relationship is simple: the same the developers have with their Product Owners
55. Domain Driven Design – Application Services
• Handle domain-wide transactions
• Understand domain language
• Application transactions are
eventually consistent
ApplicationService
Domain Service
Domain Service
Domain Service
61. TDD for Domain Driven Design
Green
(Work)
Refactor
(Refine)
Red
(Design)
Optional
62. TDD for Domain Driven Design
• Red
• Design the simplest concept required for a functional prototype
• Less classes are best! Think always about abstractions
• Green
• Just make it work
• Refactor
• Do not refactor for better code
• Do not design if you don´t have enough business knowledge
• Design top-down if you are not sure about the functionality
63. TDD for Domain Driven Design
Red Green
Acquire
Business
Knowledge
Refactor
64. TDD – Refactor
• Refactor is not a tool for better code!
• Refactor is a tool for better abstractions!
• Do not refactor until you have better knowledge of the problem.
65. TDD – Refactor Direction
Application
Service
Domain
Service
Aggregate
Root
Abstraction Level
66. TDD – Refactor
• Do not forget component responsibility
• When refactoring, Domain Services must be always responsible of one
domain and ACID
• Do not break abstractions never
• If you need to break something, always break encapsulation instead of
abstractions
• Commits are a unit of time, software evolves, don’t try to create
perfect code
