Introduction to Domain-Driven Design
- 1. A Quick Introduction to Domain-Driven Design Tackling the Complexity at the Heart of Software Rafael Azevedo
- 2. Software Development is Challenging! • People / Organisa5onal Challenges • Technology Challenges • Design Challenges Intricacies, uncertain<es, complexi<es!!! Introduction to Domain Driven Design
- 3. “Divide et Impera” Philip II of Macedon 382–336 BC Julius Caesar 100–44 BC Napoléon Bonaparte 1769–1821 Introduction to Domain Driven Design
- 4. Divide and Conquer Approaches Introduction to Domain Driven Design https://jpattonassociates.com/dont_know_what_i_want Increments Itera5ons
- 5. Introduction to Domain Driven Design
- 6. “The beginning of wisdom is the definition of terms.” Socrates (470 – 399 B.C.) Introduction to Domain Driven Design
- 7. Domains and Models A domain is sphere of knowledge, influence, or activity. A model is a selectively simplified and consciously structured system of abstractions that describes selected aspects of a domain and can be used to solve problems related to that domain. An appropriate model makes sense of information on a domain and focuses it on a problem. Introduction to Domain Driven Design
- 8. Context and Language Context is the seHng in which a word or statement appears that determines its meaning. Statements about a model can only be understood in a context. Bounded Context is a descrip5on of a boundary within which a par5cular model is defined and applicable. Ubiquitous Language is a language structured around the domain model and used by all team members within a bounded context to connect all the ac5vi5es of the team with the soKware. Introduction to Domain Driven Design
- 9. Putting the Domain Model to Work 1. The domain model is distilled knowledge. 2. The domain model and the heart of the design shape each other. 3. The domain model is the backbone of a language used by all team members. Introduction to Domain Driven Design
- 10. The DDD Approach to Software Development 1. Focus on the core domain. 2. Explore models in a creative collaboration of domain practitioners and software practitioners. 3. Cultivate a ubiquitous language within an explicitly bounded context. Introduction to Domain Driven Design
- 11. Some DDD Building Blocks Introduction to Domain Driven Design
- 12. Value Objects Value Objects describe or compute some characteristic of a thing. Introduction to Domain Driven Design
- 13. Entities and Aggregates An entity represents a thread of continuity and identity, going through a lifecycle. An aggregate is a cluster of value objects and its root entity that defines a boundary of consistency. Introduction to Domain Driven Design
- 14. Domain Events Domain Events provide a discrete representation of relevant facts or changes in the state of entities. • Activity in a domain is modelled as a series of domain events. • In a distributed system, the state of an entity can be inferred from the domain events currently known to a particular node, allowing a coherent model in the absence of full information about the system as a whole. Introduction to Domain Driven Design
- 15. Does it really matter? Introduction to Domain Driven Design
- 16. Mars Climate Orbiter Spacecraft On September 23, 1999 NASA lost this $125 million spacecraft after a 286-day journey to Mars. Introduction to Domain Driven Design
- 17. What is wrong with this code? def upward_thrust(Float target_position, Float actual_position) Float deviation = actual_position.vertical - target_position.vertical Float correction = calculate_vertical_thrust_adjustment(deviation) return correction end Introduction to Domain Driven Design
- 18. Is this better? interest_rate = InterestRate.new(3.5, :percentage, :annually) interest_period = Period.new(Date.new(2018, 1, 1), Date.new(2018, 1, 9)) principal = Amount.new(300.00, 'AUD’) interest = interest_rate.apply(principal, interest_period) Introduction to Domain Driven Design
- 19. DDD in our tool set Introduction to Domain Driven Design
- 20. When and Where should we use DDD? Domain Problem X Technical Problem Introduction to Domain Driven Design
- 21. When and Where should we use DDD? ü Complicated => benefits from clarity and precision ü Innovative => demands continuous learning and change ü High Value => affords longer term investment Introduction to Domain Driven Design
- 22. When and Where should we use DDD? High commitment for intense & continued collaboration between domain practitioners and software practitioners Introduc5on to Domain Driven Design
- 23. Wrapping-Up • DDD primarily addresses complexity in the domain, through evolving design models that foster learning, clarity and preciseness. • DDD engages domain and software experts in deep collaboration, based on intentional language and explicit bounded contexts. • DDD provides a pattern language for software design; we covered value objects, entities/aggregates, commands/events. • DDD is a tool, best suited • for high value, complex/complicated, innovative domain problems; • for organisations highly committed to consistent and effective collaboration. Introduction to Domain Driven Design
- 24. Introduction to Domain Driven Design
- 25. Actually, there is so much more! Introduction to Domain Driven Design Ralph Johnson “Eric Evans has wriien a fantas5c book on how you can make the design of your soKware match your mental model of the problem domain you are addressing.” . . . “The book is a fun read. Eric has lots of interes5ng stories, and he has a way with words. I see this book as essen5al reading for soKware developers—it is a future classic.”