The document discusses the principles of Domain Driven Design (DDD), emphasizing the importance of correctness, testability, and ease of change in software development. It introduces concepts such as domain events, aggregates, and value objects, highlighting the need for clear communication and the establishment of patterns within a domain. The document also provides practical examples and emphasizes the importance of adapting domain designs to meet specific requirements.

1. Domain Driven Design
Josh Dastmalchi

2. Let’s Drive a Manual Car

3. How do we shift gears?
• Press the clutch pedal to the floor
• Use the gear shift to change gears
• Depress the clutch pedal while also pressing the gas pedal

4. Okay, Let’s Drive!

5. The Importance of Why, What, When

6. Priorities

7. Correctness
• If it doesn’t do what we intended, we have failed.
• Testability – how do I know I’m correct?

8. Ease of Change
• Software is never done.
• An anecdote: “This requirement will definitely never change”

9. Methods

10. Ubiquitous Language
• To achieve correctness, we must communicate the product needs.
• If we're not speaking the same language, we're off to a bad start.
• What if we all had different native languages?

11. The Boot

12. Contextless Truth
• The truth of a domain exists outside of any user interface or database.
• Use Cases:
• The domain defines truth - what is possible in reality
• A use case defines what is possible in the application

13. Patterns
• Establishing patterns takes the mystery away from doing common tasks.
• Command-Query Responsibility Segregation
• Repository
• Hexagonal

14. The Code
What everyone really wants to see

15. Domain Events
Represents a change of state in our domain.
• All domain mutations produce domain events recording them.
• Event handlers can listen for these events and perform actions accordingly
• Enables event sourcing, a powerful but complex way to store domain history.

18. Domain Events: My experience
• They won’t feel useful initially – but they unlock a lot of power for later
complexity.
• Generally there are two types of handlers:
• Handlers that enforce domain rules of the form “When x, then y”
• Handlers that inform other systems of changes in our domain
• Include enough information in events to make them reversible
• Prefer domain services or entities to event handlers

19. Entities
Represents a concept in our domain.
• Has an immutable unique identifier.
• Enforces invariants (domain rules) and never allows itself to be in an invalid state.

20. Aggregates
Aggregates are a special type of entity.
• An aggregate cannot be nested in another entity's object graph.
• An aggregate can be referenced by ID by another entity.
• Non-aggregate entities do not track events.
• Non-aggregate entities do not have public methods.

28. Aggregates: My Experience
• Minimize aggregate size.
• (Almost) never use non-aggregate entities.

29. Value Objects
Represents a complex property in our domain.
• In contrast to entities, equality is determined by a value object’s properties, not a
unique identifier.
• Like entities, these are self-validating.

35. Value Objects: My Experience
• For primitive types, always consider wrapping them in a value object.
• If an entity has complex validation across multiple properties, consider wrapping
them all together as a value object.
• Wrapping your aggregate identifiers as value objects provides type safety in a
place where it is very easy to make mistakes.

36. Domain Service
• An implementation of orchestrated domain logic that can’t be put on an
aggregate
• Common reasons to use a service:
• Uniqueness checks
• Configuration-based logic
• Interaction with multiple aggregates

43. Domain Services: My Experience
• Use single-purpose services and composition instead of large services
• Avoid an anemic domain: prefer entity-based logic over service-based logic
• If an entity method requires service orchestration, use access modifiers to prevent
non-domain calls

44. Major Takeaways: Why
Priorities
1. Correctness
2. Ease of change
Methods
• Ubiquitous language
• Contextless truth

45. Major Takeaways: How
• Domain design: Correctness & Ease of Change
• Domain logic: Entity > Service > Event Handler
• Small entities, small services

46. Live Demo

47. Real Practice – Adapting the Domain
• A doctor’s name must be at least 3 characters, can be no more than 50 characters, and
must consist of only alphanumeric characters.
• An appointment can only be scheduled in increments of 15 minutes. Specifically,
appointment times must end in :00, :15, :30, or :45.
• Doctors get days off – holidays, time off, etc. We should add a concept of a doctor’s
time off that specifies a date and hours on that date during which a doctor is
unavailable. This should prevent appointments being scheduled during that time and
delete any existing appointments during that time. Time off should only be able to be
scheduled in the future.

48. Links
• Source Code: https://github.com/josh-dastmalchi/ddd-example