While Object Oriented Programming provides a basis for structuring code, the question "How do I make sense of all those business rules?" remains unanswered. Domain Driven Design (DDD) main goal is to manage complexity by defining how to translate domain logic to code.

1. What is Domain Driven
Design and why it matters

2. Managing complexity
● Software projects are increasingly complex and sophisticated.
● Systems integrates with many third party services
● Modern databases, hardware and tools makes it easier to create bigger
systems
● Design techniques commonly taught (UML, design patterns, SOLID) don’t
help much handling massive projects

3. Taking a bike for a ride. Simple, right?

4. Under the cover
● Handling payment and sensitive information (credit card).
● Detecting a bike is returned is not 100% reliable
● Sensors or other hardware component may fail
● Finding suitable station for renting/returning a bike
● Many different ways of billing a client

5. Complexity - Where does it come from?
● Mixing business logic with infrastructure concerns
● Inherent complexity of the domain itself (accounting, physics, shipping,
etc)
● Number of concepts to know in order to accomplish a task.
● Sheer size. A feature may be simple in isolation but complex in a system,
given how it links with it

6. Symptoms of acute complexity illness
● Difficulty explaining a concept or action
● Adding a feature automatically means modifying other parts of the system.
(Reports, other modules)
● Recurring communication issues between customers, support, sales and
devs on a particular topic

7. Old ideas in a new(ish) package
● DDD is a unified collection of patterns and guidelines
● The value is in “tackling complexity”, defining how all its elements and how
they are used to reach that goal
● A pattern is a tool, not a solution by itself. A tool must be used diligently,
for a reason.

8. Ubiquitous Language
The terms and their definition in a domain.
Words commonly have many definitions and sometimes are misused.
A domain dictionary defines all the terms and definitions, providing one global
source of truth

9. A dangerous source of spaghetti code

10. A class management system
- Special pricing for children.
- Tax credit for children
- Child only activity
- Different forms for adult and children
Modeling with objects -> Children and Adult classes, maybe a common base
class. Simple enough(?)

11. From the dictionary
- person between birth and puberty.
- A person who has not attained maturity or the age of legal majority.
- One who is childish or immature.
- A son or daughter; an offspring.
- A member of a tribe; descendant.
- An individual regarded as strongly affected by another or by a specified
time, place, or circumstance: a child of nature; a child of the Sixties.

12. Definitions from the use cases
- Government considers a child, for tax credits purpose, is between 6 and 14
years old.
- Below majority in most cases (Wait, majority in which country?)
- What happens when the child reaches majority? Need to convert the data?
- New feature request: special pricing and tax credits for seniors.

13. The solution

14. Repairing the table
- Turns out the only thing we actually care about is age.
- The child and adult concepts create multiple edge cases to handle for zero
added value.
- One single class is a better fit given this context.

15. An alternative design - Specification pattern
Eligibility criterion
Bool isEligible(Client)
Age
Subscription

16. (Bounded) Contexts
How can we understand each other when words have fuzzy meaning and
multiple definitions?
Humans are clever and can correct ambiguities themselves. How? By using the
current context to make logical deductions.
Machines have no taste for poetry, metaphors and figures of speech.

17. - A domain model represents a concept and puts it in a structured way.
- Concepts, attributes, how do they relate to each other
- A real-object can be modeled in many ways, there is no right answer.
- A good model captures the relevant aspects for a given context and leaves
out the irrelevant details.
- A given model can be both accurate and useless
Domain model

18. Administrative map of Quebec

19. Aggregates
- Technical pattern.
- Defines consistency units, composed of one or many entities.
- Enforces invariants.

20. Docking station as aggregate root
Docking Station Screen
Bike
Docking port

21. Takeaways
- Define a clear vocabulary and spread that knowledge
- A definition is usually coupled to a given context
- Complex domains can be dealt with using modeling techniques
- A concept maps to many models - find one appropriate to your context

22. Questions?
Thank you for attending!
@plmaheu