Domain Driven Design (Ultra) Distilled
0 likes284 views
The document discusses Domain-Driven Design (DDD), highlighting it as a toolbox for creating software that effectively meets business needs through a shared language between developers and users. It emphasizes the importance of thoughtful design to avoid poor abstractions and improve integration between different parts of the business. Techniques such as event storming and context mapping are outlined to facilitate collaboration and alignment between domain experts and developers.
Domain Driven Design (Ultra) Distilled
- 2. Domain-Driven Design (DDD) - What • IS.. • a toolbox (set of pattern) of the best software modeling tools available, to assist in design and implementation of software that delivers high value – both strategically and tactically • MEANS… • learning through the team communication for building a model based on an Ubiquitous language • Making competitively best software design choices and integration decision for the business
- 3. Domain-Driven Design (DDD) - Why • TO IMPLEMENT SOFTWARE THAT • correctly models business’ needs • performs at a scale using most advanced techniques
- 4. Stop u “Task board shuffle” u Scrum if for knowledge acquisition, not time control u Chasm between business’ and developers’ mental models u Wrong abstractions Start u Thoughtful design u Effective design u Strictly modeled around business’ needs u It will evolve naturally with the business because it has been created to be adherent to the business itself
- 5. “ ” Questions about whether design is necessary or affordable are quite beside the point: design is inevitable. The alternative to good design is bad design, not no design at all. DOUGLAS MARTIN, 1989 Design is inevitable: the alternative to good design is bad design, not no design at all!
- 6. Ubiquitous Language uCreate a common, rigorous language between developers and users.
- 7. Event Storming u ”Rapid design technique to engage both Domain Experts and Developers in a fast-paced learning process.” u Focused on the business and business process rather than on nouns and data.
- 9. Event Storming uDifferent colors for each component uDifferent shapes for each context
- 11. Context Mapping INTEGRATION BETWEEN THE CORE DOMAIN AND OTHER BOUNDED CONTEXTS
- 13. Context Mapping u Partnership u 2 teams working on 2 bounded contexts have aligned and dependent set of goals u Shared kernel u 2 or more bounded contexts can share a common model u Customer supplier u 2 bounded contexts into an upstream and downstream, where the upstream is the supplier, and has to try and meet the expectations of the customer (downstream) u Conformist u 2 bounded context, the upstream has no interest in supporting the downstream for whatever reason. The downstream must conform to whatever the upstream provides u Anticorruption Layer u the downstream bounded context implements a layer between itself and the upstream u Open Host Service (OHS) / Published Language (PL) u Protocol or interface that gives access to the Bounded Context as a set of services u Published Language u Well-documented information exchange language enabling simple consumption and translation by any number of Bounded Context u Separate Ways u Situation where integration with one or more Bounded Context will not produce significant payoffs through the consumption of various Ubiquitous Languages u Big Ball of Mud u software system that lacks a perceivable architecture