How to create better code using Domain Driven Design

Slides present examples of accidental complexity and issues related to developing anemic domain models and introducing too many abstractions not satisfied by actual functional needs. Later usage of tactical DDD patterns like entity, value object, domain service, factory, repository, and application service makes code more readable and expressive.

Transcript

1. altkomsoftware.pl Domain Driven Design Introduction Wojtek Suwała, ASC LAB Head Architect
2. altkomsoftware.pl v altkomsoftware.pl 2
3. altkomsoftware.pl altkomsoftware.pl Software development is easy, isn’t it? From 2011 to 2015 the percentage of successful IT projects remains unchanged on a level of just 22% 3 We must be doing something wrong ... The rest have experienced challenges Over 19% of all projects failed We are developing software since 1960’s, yet:
4. altkomsoftware.pl altkomsoftware.pl Complexity 4 Good complexity Domain logic complexity inherent to the domain itself. Bad complexity Accidental complexity from: • mixing problem space with solution space • lack of understanding of business domain • mixing technical solution complexities
5. altkomsoftware.pl altkomsoftware.pl 5 Mixing domain complexity with technical complexity Complexity
6. altkomsoftware.pl altkomsoftware.pl 6 Developers Enterprise Software Development Best Practices Business
7. altkomsoftware.pl altkomsoftware.pl 7 7 Enterprise Software Development Best Practices
8. altkomsoftware.pl altkomsoftware.pl 8 8 Enterprise Software Development Best Practices
9. altkomsoftware.pl altkomsoftware.pl How about doing it right Domain-Driven Design is a language anddomain-centric approach to softwaredesign for complex problem domains. The term was coined by Eric Evans in his Complexity from the domain is inherent seminal book “Domain-Driven Design: Tackling Complexity in the Heart of Software”. It consists of a collection of patterns, principles and practices that will enable teams to focus on what is core to the success of the business while crafting software that manages complexity in both the technical and business spaces. 9
10. altkomsoftware.pl v altkomsoftware.pl 10 What do you mean when you say Software Development? Software development is a collaborative learning process involving developers and business experts.
11. altkomsoftware.pl v altkomsoftware.pl 11 Problem Space Understanding customer’s business domain Building shared language What is our customer’s core business? What are customer’s goals? What problems we are trying to solve? Where our customer can gain / lose money?
12. altkomsoftware.pl v altkomsoftware.pl 12 Big Picture Event Storming
13. altkomsoftware.pl v altkomsoftware.pl 13 Domain Storytelling
14. altkomsoftware.pl v altkomsoftware.pl Big Picture Exploration Outcomes: Better understanding of business domain Initial business concepts definitions Hot spots and opportunities revealed Big Domain initially divided into smaller parts - subdomains 14
15. altkomsoftware.pl altkomsoftware.pl Not All Parts Of The Problem Are Equal 15
16. altkomsoftware.pl v altkomsoftware.pl 16 Subdomains
17. altkomsoftware.pl altkomsoftware.pl Subdomains types Core domain - the core thing identifies customer’s business and distinguished them from competitors. This is where we should focus on and where we can send our best troops. Supporting domains - things that must be done in order to support core business but are not unique. No need to spend lot of time modelling it. Probably existing patterns can be used. Less skilled teams can be assigned. Generic domains - things most enterprises do in the same way. Can be bought/outsourced. 17
18. altkomsoftware.pl altkomsoftware.pl Supporting / generic subdomains 18
19. altkomsoftware.pl altkomsoftware.pl Subdomains - Finding Core Agile Estimation can be used to identify Core and where we should apply DDD tactical patterns versus CRUD. On the other side, there is the Complexity/Cost that is associated with implementing software to manage the Bounded Context. Subdomains with Large Competitive Advantage and Large Complexity/Cost are the ones we should focus our effort on. Alternatively use Impact Mapping. 19
20. altkomsoftware.pl altkomsoftware.pl Solution Space Bounded Contexts Models Ubiquitous Language Context Maps 20 Defining right solution to the right problem with a little help of …
21. altkomsoftware.pl altkomsoftware.pl Corporate Model Anti-Pattern Developers and Analysts are often trying to create one big model that has all data and handles all the use cases. We try to “sum up” many people different views on given term. This approach leads to having brittle, complex models full of unnecessary abstractions. It brings lots of accidental complexity to our solution. Such model is hard to extend and maintain over time. It is makes dividing work and responsibility to teams very hard. 21
22. altkomsoftware.pl altkomsoftware.pl Don’t put everything into one model 22 Policy Create Offer, Buy Policy Annex, Terminate Register Case Approve Case Payment Register Payment Change Payment Schedule Create Renewal Offer, Renew Calculate Reserves Calculate Commission Renewals Claims handling Payments Accounting & Reporting Sales Policy Managemen
23. altkomsoftware.pl altkomsoftware.pl Don’t put everything into one model 23
24. altkomsoftware.pl altkomsoftware.pl Bounded Context & Ubiquitous Language Bounded context divide solution space into smaller parts where we work on smaller models. Bounded context defines applicability of the model. It gives clarity on what is model used for, where is should be consistent and what it should ignore. Bounded context protects model inside it from things outside of it. Model should only change to better support functionality it is designed for, not due to requirements external to it. Bounded context gives team assigned to it autonomy and protection. 24
25. altkomsoftware.pl altkomsoftware.pl Bounded Context & Ubiquitous Language Given domain term has precise meaning in given context. Project language shared between devs and customer and reflected in code must be precise in given bounded context. 25
26. altkomsoftware.pl altkomsoftware.pl Bounded Context & Ubiquitous Language Example: E-Commerce System Product in context of Sales is described by price, available models, technical specification. It exposes two capabilities: can be sold and can be found by various criteria. Product in context of Shipping is described in terms of weight, package size, package handling rules, warehouse location and stock. It exposes capabilities: can be found, can be shipped, new stock can be placed and located. 26
27. altkomsoftware.pl altkomsoftware.pl Bounded Context & Ubiquitous Language Bounded contexts should be created around business capability, not around data. Bounded contexts tend to align with customer organization’s structure - Conway’s Law 27
28. altkomsoftware.pl altkomsoftware.pl Bounded Context & Ubiquitous Language 28
29. altkomsoftware.pl altkomsoftware.pl What is domain model? Domain model is central part of Domain Driven Design. We focus on creation and further enhancements of domain models. It’s first version comes as analytical model from collaboration of devs and business experts during design and knowledge crunching sessions. It represents view of the domain needed to support business use case. It is not model of real world. It needs to evolve iteratively to keep itself useful. Domain model is expressed in code. Code model is bound to analytical model through Ubiquitous Language. 29
30. altkomsoftware.pl altkomsoftware.pl Domain model The code is primary expression of the domain model. You should take care of keeping code and conceptual model in sync. If during implementation you need to express new ideas or change meaning of already defined things, this should also be reflected in the language you communicate with domain expert. The same care must be taken to handle changes coming from business understanding or requirements changes. 30
31. altkomsoftware.pl altkomsoftware.pl Domain model 31
32. altkomsoftware.pl altkomsoftware.pl How to create a good model 32 Domain modelling is a team activity Domain model is not a model of a real life Model only what is relevant Domain models are temporary useful Be explicit with terminology Limit your abstractions Implement model in code early and often Don’t stop at first good idea Remember: All models are wrong, but some are useful
33. altkomsoftware.pl v altkomsoftware.pl 33 Event Storming Design Level
34. altkomsoftware.pl v altkomsoftware.pl Event Storming Design Level 34
35. altkomsoftware.pl v altkomsoftware.pl 35 DDD Modeling Whirlpool
36. altkomsoftware.pl altkomsoftware.pl Context Maps Context map define how different bounded contexts are integrated (how they communicate with each other - at the system level and at the teams level) and how language of one context is translated into language of the other. Context mapping strategies: Shared Kernel, Customer/Supplier, Conformist, Anti Corruption Layer, Separate Ways, Open/Host Service, Published Language, Partnership 36
37. altkomsoftware.pl altkomsoftware.pl Key Tactical Patterns - Aggregate Aggregate - “clusters” of things tightly related together in given context. Aggregate takes care of keeping its state consistent and holding invariants. Invariant is business rule / characteristic of a thing that state must be compliant to. From developers perspective Aggregate is a scope of transactional processing. All things within aggregate are saved successfully together or save fails reverting state to the original one. Aggregate Root - main element of aggregate, all access to aggregate is performed only through the aggregate root. 37
38. altkomsoftware.pl altkomsoftware.pl Aggregates - Example: Online Actions Bounded Context 38 Winning Bid Bid Member Category Shipping Method Seller Answer Auction Item Auction Payment Method Question
39. altkomsoftware.pl altkomsoftware.pl Aggregates - Example: Online Actions Bounded Context 39 Auction Winning Bid Bid Member Payment Method Category Shipping Method Seller Question Answer Auction Item
40. altkomsoftware.pl altkomsoftware.pl Good aggregate design rules Design around domain invariants, keep inside only data that is needed to hold invariants while supporting operations Reference things outside only by ID Favour small aggregates Large aggregates degrade performance Large aggregates are potential source of concurrent access issues Ignore user interface influences Avoid dumb collections and containers Don’t focus on HAS-A relationship, your data model is not your aggregate model Do not model real life, only your use case 40
41. altkomsoftware.pl altkomsoftware.pl Key Tactical Patterns - Domain Events Domain Event - fact that describes something that happened in your domain, something with business meaning. Domain events are a tool that allows us to have communication between aggregates. Domain events live inside bounded context. One aggregate subscribes to events of other aggregate and adjust its state. Application may subscribe to domain events to perform technical actions: like e-mail sending. Domain Events can contain references to domain objects in scope of Bounded Context. 41
42. altkomsoftware.pl altkomsoftware.pl Key Tactical Patterns - Domain Events There is also a completely different kind of Domain Events. External Domain Events - that are used to communicate between bounded context. This kind needs different approach. Such events must be versioned and cannot carry domain objects. 42
43. altkomsoftware.pl v altkomsoftware.pl Tactical Patterns – DDD Design Building Blocks Entities Value Objects Repositories Domain Services / Policies Specifications Factories Application Service / Command Handlers 43
44. altkomsoftware.pl v altkomsoftware.pl DDD & Architecture Popular architectures often used when doing DDD: Onion Architecture Ports and Adapters CQRS … any many many others but remember DDD is not architecture 44
45. altkomsoftware.pl v altkomsoftware.pl 45 DDD & Architecture: Onion
46. altkomsoftware.pl v altkomsoftware.pl 46 DDD & Architecture: Ports & Adapter (Hexagonal)
47. altkomsoftware.pl v altkomsoftware.pl 47 DDD & Architecture: CQRS
48. altkomsoftware.pl altkomsoftware.pl DDD Misconceptions DDD is technical thing DDD is about Entities, Value Objects, Repositories DDD requires usage of ORM, Spring, ... DDD is a framework DDD is architecture 48
49. altkomsoftware.pl altkomsoftware.pl DDD things to remember DDD is great for: divide important stuff from less important :) Focus on small but important part Build shared language of the project that is used For communication between devs and business Build models through iterative collaboration with domain experts Move shared language from discussion and modelling sessions into code 49
50. altkomsoftware.pl altkomsoftware.pl 50 Dziękujemy za uwagę. altkomsoftware.pl github.com/asc-lab Twitter: @AltkomSC asc-lab@altkom.pl