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.

1. Domain Driven Design
DAY 1

2. Spoiler
• DDD is not for the perfectionist

3. Spoiler
• DDD is not for the perfectionist

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

6. Delivering Software
• Focused on the final client
• Use the same language
• Iterate over the requirements

7. Delivering Software => Complexity

8. Delivering Software => Complexity

9. Delivering Software => Complexity
Technical Debt

10. Delivering Software => Complexity

11. Delivering Software => Complexity

12. Solution
• Focus on business direction
• Strategic DDD
• Keep software as small as possible
• Tactical DDD

13. Strategic DDD
•Business
Knowledge

14. Strategic DDD
• Business Knowledge
• Technology is not important if it doesn’t fulfill its objective
• Solve people problems

15. Strategic DDD
• Ubiquitous Language
• Bounded Context
• Context Mapping

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)

29. Model Driven Design vs Service Driven Design

30. Model Driven Design

31. Model Driven Design (with ADT)

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

36. Invariants

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

40. Model Composition

41. Domain Driven Design
• Layered Architecture
• 3 essential Layers
• Application
• Domain
• Infrastructure
• Model-centric
• Focused on data integrity
Domain
Application
Infrastructure

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

45. Domain Driven Design – Entity

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

47. Domain Driven Design – Value Object

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

51. Domain Driven Design – Domain Services
• As A Visitor, I want to login

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

56. Domain Driven Design – Application Services

57. Domain Driven Design & Test Driven Development

58. Domain Driven Design & Test Driven Development
•Are Friends 

59. TDD
• A tool for designing software
• The developer designs software while acquiring business
knowledge

60. TDD Basics
Green
(Work)
Refactor
(Refine)
Red
(Design)

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