Download as PDF, PPTX
![Let’s Talk About Design…
▪ Do you do it?
▪ Big-Design-Up-Front vs Emergent Design
▪ “Working software over comprehensive documentation”
[Agile Manifesto]
▪ “Continuous attention to technical excellence and good
design enhances agility”
[Principles behind the Agile Manifesto]
▪ While we must acknowledge emergence in design and
system development, a little planning can avoid much
waste
[James Coplien, Lean Architecture]](https://image.slidesharecdn.com/dddesignpublic-160729085900/85/Modelling-a-complex-domain-with-Domain-Driven-Design-10-320.jpg)
![The Problem You’re Trying to Solve
▪ Complexity inherent in software
▪ Essential & Accidental complexity
▪ “That’s not what I meant” [An End User]](https://image.slidesharecdn.com/dddesignpublic-160729085900/85/Modelling-a-complex-domain-with-Domain-Driven-Design-19-320.jpg)
![Let’s Talk About Design…
▪ Do you do it?
▪ Big-Design-Up-Front vs Emergent Design
▪ “Working software over comprehensive documentation”
[Agile Manifesto]
▪ “Continuous attention to technical excellence and good
design enhances agility”
[Principles behind the Agile Manifesto]
▪ While we must acknowledge emergence in design and
system development, a little planning can avoid much
waste
[James Coplien, Lean Architecture]](https://image.slidesharecdn.com/dddesignpublic-160729085900/75/Modelling-a-complex-domain-with-Domain-Driven-Design-10-2048.jpg)
![The Problem You’re Trying to Solve
▪ Complexity inherent in software
▪ Essential & Accidental complexity
▪ “That’s not what I meant” [An End User]](https://image.slidesharecdn.com/dddesignpublic-160729085900/75/Modelling-a-complex-domain-with-Domain-Driven-Design-19-2048.jpg)
Uploaded byNaeem Sarfraz
Modelling a complex domain with Domain-Driven Design
The document discusses domain-driven design (DDD), emphasizing the need for software to reflect the problem domain through collaboration between domain and software experts. It outlines key concepts such as ubiquitous language, bounded context, and the importance of focusing on core complexity while avoiding pitfalls like anemic domain models. The document advocates for a domain-centric approach to modeling that enhances understanding and efficiency in software development.
More Related Content
Similar to Modelling a complex domain with Domain-Driven Design
Modelling a complex domain with Domain-Driven Design
- 1. Modelling a complexdomain with Domain-Driven Design @NaeemSarfraz #DDDesign #LeedsSharp
- 4. Can you tellme what is the problem you’re trying to solve?
- 6. Is it possibleto write code that reflects the problem domain?
- 7. Could you deducethe original requirements from your code?
- 8. Who am I? SolutionsArchitect @ Barrett Steel 10+ years .NET Developer Learn(new Things()).Like() Play(Archery).Add(Horseriding).Like() @NaeemSarfraz http://naeemsarfraz.net
- 9.
- 10. Let’s Talk AboutDesign… ▪ Do you do it? ▪ Big-Design-Up-Front vs Emergent Design ▪ “Working software over comprehensive documentation” [Agile Manifesto] ▪ “Continuous attention to technical excellence and good design enhances agility” [Principles behind the Agile Manifesto] ▪ While we must acknowledge emergence in design and system development, a little planning can avoid much waste [James Coplien, Lean Architecture]
- 14.
- 15. What Is Domain-DrivenDesign? 1. Focus on the core complexity and opportunity in the domain 2. Explore models in a collaboration of domain experts and software experts 3. Write software that expresses those models explicitly 4. Speak a ubiquitous language within a bounded context
- 17.
- 19. The Problem You’reTrying to Solve ▪ Complexity inherent in software ▪ Essential & Accidental complexity ▪ “That’s not what I meant” [An End User]
- 20. Definitions… Problem Domain ▪ Asphere of knowledge, influence, or activity ▪ The subject area to which the user applies a program
- 21. Language ▪ The primarycause of misunderstanding between business & development teams ▪ Agree and define key conceptsprocessesactors – a shared vocabulary ▪ Avoid translations ▪ Language is reflected in code ▪ Who? – Domain Expert (not a Product Owner) – Development Team
- 22. Definitions… Ubiquitous Language ▪ Alanguage structured around the domain model and used by all team members within a bounded context to connect all the activities of the team with the software
- 23. Context ▪ Language hasa meaning within a context ▪ A Model only has meaning within a context ▪ One Model to rule them all! ▪ Systems serve different user communities ▪ Define the context within which a model applies – Library Loans ▪ Borrower of a Book – Library Fines ▪ Member of a Library
- 24. Definitions… Bounded Context ▪ Adescription of a boundary (typically a subsystem, or the work of a particular team) within which a particular model is defined and applicable
- 25. Modelling ▪ Start withthe key concepts in your problem domain ▪ Explore the interactions between these conceptsclasses ▪ Domain Model expressed as an Object Model ▪ Turn key concepts into pertinent classes ▪ Useful models not necessarily realistic ▪ Key: Domain-centric model not Data-centric
- 32. Definitions… Model ▪ A systemof abstractions that describes selected aspects of a domain and can be used to solve problems related to that domain Domain Model ▪ An object model of the domain that incorporates both behaviour and data
- 33. Our Problem Domain ▪As a Purchaser I want to be able to request to purchase goods for independent depots So that I can purchase goods on behalf of each specific business ▪ As a Purchaser I want to be able to request to purchase goods that are required for multiple depots So that I can reduce the amount of time taken to raise purchase orders required for each depot ▪ As a Manager I want to be able to approve or reject a purchase request So that we can follow the defined business approval process ▪ As a Purchaser I want to be able to self-approve an order with my self-approval limit So that I can purchase items which require no approval
- 34. What are theKey Concepts?
- 39. The core domainis the part of the domain most closely associated with the strategy of the company Core Domain
- 40. Purpose Alignment Model MarketDifferentiation MissionCritical Does anyone care? Invest Parity Partner Partner – Do we need to take this on? Find a partner Parity – Achieve and maintain parity Invest – Excel and innovate here, support USP Core Domain Supporting Sub-Domain Generic Sub-Domain
- 43. Entities ▪ An individual“thing” ▪ Has an identity ▪ Has a life ▪ Mutable ▪ Equality comparison using identity
- 44. Value Objects ▪ “PrimitiveObsession” ▪ Doesn’t have an identity ▪ Equality comparison using properties ▪ Immutable
- 45. A Word AboutImmutability ▪ More Immutable structures = betterreliable code ▪ Type safety ▪ Side-effect free ▪ Try to move behavioural responsibilities into Value Objects ▪ Keep management of state in the Entity
- 49. Definitions… Entities ▪ Objects thathave a distinct identity that runs through time and different representations Value Objects ▪ A small simple object, like money or a date range, whose equality isn't based on identity
- 50. Beware of Anti-Patterns ▪Anaemic Domain Model ▪ The Leaky Model ▪ Partially Initialised Entities
- 51. Domain Services ▪ Sometimes,it just isn’t a thing ▪ First class citizens so name is part of Ubiquitous Language ▪ Exposed as a service ▪ A stateless operation ▪ Examples: – LoanAnItem – PlaceReservation ▪ Not an Application Service – IEmailSender – These depend on Infrastructure
- 52. Domain Events ▪ Somethinghappened that the domain expert cares about ▪ First class citizens so name is part of Ubiquitous Language ▪ Named in the past tense e.g. ItemWasLoanedEvent ▪ Immutable – a record of something in the past
- 54. Definitions… Domain Service ▪ Aprocesstransformation in the domain that is not a natural responsibility of an entity or a value object Domain Events ▪ A full-fledged part of the domain model, a representation of something that happened in the domain
- 55. Aggregates ▪ Collection ofEntities and Value Objects treated as a conceptual whole ▪ Root Entity is the Aggregate’s conceptual name ▪ Business defines the invariants ▪ External references are restricted to the root only ▪ Smaller the better ▪ Consistency: – Logically consistent within an Aggregate via transaction – Eventually consistent across Aggregates via propagating updates async ▪ Repository used to load and save an Aggregate
- 56. Definitions… Aggregate ▪ A clusterof associated objects that are treated as a unit for the purpose of data changes
- 57. Presentation Layer Business Layer DataAccess Layer Data Storage Layer
- 60.
- 62.
- 63. Model Exploration Whirlpool ▪Start with a reference scenario ▪ Propose a model ▪ Code probe ▪ Repeat
- 65. Event Storming ▪ Takeone big room with lots of clear surfaces ▪ Add Domain Experts and Developers ▪ Give them lots of sticky notes & sharpies (trust me you’ll need lots) ▪ And get them to…talk?
- 66. Time Book Reserved Book Returned Member Pays Money Book Loaned Fine Paid Lorem Ipsum Dolored Lorem Ipsum Dolored Lorem Ipsum Dolored Lorem Ipsum Dolored Lorem Ipsum Dolored Canwe pay later? Lorem Ipsum Dolored What’s if the book is never available Places Reservation Can we pay half the fine?
- 67.
- 73. In Summary ▪ Knowingwhen to use it ▪ Domain centric modelling not data centric ▪ Work with your Domain Experts ▪ Give OO Design another chance ▪ Use Value Objects ▪ Do some f@*?ing design
- 74. Thank You Any Questions? t:@NaeemSarfraz e: Naeem.Sarfraz@gmail.com
- 75. Follow up… Events ▪ DDDEurope 2017 - Amsterdam – https://dddeurope.com/2017 ▪ DDDx 2017 – London – https://skillsmatter.com Pluralsight ▪ Domain-Driven Design in Practise ▪ Domain-Driven Design Fundamentals