DDD Introduction
•Download as PPTX, PDF•
0 likes•88 views
Domain Driven Design is a system of Modeling and Design that helps projects to align complex software systems with business needs
Recommended
More Related Content
Similar to DDD Introduction
Similar to DDD Introduction (20)
More from Lorraine Steyn
More from Lorraine Steyn (9)
Recently uploaded
Recently uploaded (20)
DDD Introduction
- 2. Lorraine Steyn @lor_krs Alain King @alainkingza #DDDCapeTownwww.krs.co.za
- 4. Your assumption goes to production Our most important abilities are communication, empathy and being able to learn.
- 5. Conway's law: Organizations which design systems ... are constrained to produce designs which are communication structures of these organizations. Organization
- 6. U D Bounded Contexts Discovery… Where are users located? Which is the Core domain? Look at organizational structure
- 8. Team per Bounded Context Software helps identify better organization Shared Kernel Micro-Services
- 9. Your assumption goes to production Our most important abilities are communication, empathy and being able to learn. Safety to take risks Respect each other (internal and external to the team) Connection Prevent dysfunctional behaviour Emotional Safety
- 10. DC SKU POD RIFD Cage Blind Receiving Fulfilment Back Order FIFO ATD WAREHOUSE: Landed Cost Cross Docking Picking List Shrinkage Buffer Stock Ubiquitous Language
- 11. In source code, documentation, tests, as well as used by business 1. Natural language 2. Domain terms (not IT terms) 3. Ubiquitous Language to resolve all differences Ubiquitous Language Language that we use everywhere
- 12. Old Code: DDD Code: “year” is a Value Object
- 13. Cynefin Categorizing Complexity Disorder requires further breakdown of breakdown of the problem Better to treat a problem as more complex rather than less • Over simplification • Entrained thinking Dave Snowden & Mary Boone
- 14. Your assumption goes to production Our most important abilities are communication, empathy and being able to learn. Identify Entities (nouns), but don’t go running off to make classes! Look for verbs – what are the system actions Look for time sequences: we do this, then that… Adjectives are a hint that there may be more edge cases Challenge each discovery Ask the “dumb questions”
- 15. Modelling with the right people in the room Limited time (2-4 hours) Unlimited space Domain event Actor Command External system View
- 17. DDD Concepts Bounded Contexts Ubiquitous Language Value Objects Entities Aggregate Root Patterns: Port and Adaptor, Anti-Corruption Layer, CQRS etc Don’t let the DDD Terminology be a barrier!
- 18. Your assumption goes to production Our most important abilities are communication, empathy and being able to learn. WHY?
- 19. Like Agile, DDD is about people, collaboration, and business value
- 20. Workshops Introduction to DDD and Event Storming Ubiquitous Language, Bounded Contexts, Entities, Aggregates and Value Objects, Event Storming Intro and Case Study. Advanced DDD Exercises with Entities, Aggregates and Value Objects, Advance Bounded Contexts and exercise, Patterns: Onion, Hexagon, CQRS and Event Sourcing Implementing DDD in Code Turning your Model into code (C# exercise), and advanced modelling Case Study.
- 21. Thank you Join InDDDaba - Domain Driven Design Cape Town Meetup
Editor's Notes
- Shape the world. Software is everywhere, but hidden.
- No longer just writing software, sitting in a basement eating pizza. More engagement. Customers must stop wanting a button, and talk in terms of business value.
- Melvin Conway. We need to design our teams to match the business contexts. Bounded Contexts
- Amazon. Core domain is shopping cart. Transparent – everyone knows what to expect. Anti-corruption layer.
- In every context, words have a different meaning.
- If you feel it needs 2 teams, you probably have 2 bounded contexts. How bug can a team be? Distance more than a bus, people stop talking to each other! Distributed takes lots of effort.
- Silence / Violence. Innovation? Software development is NOT about software. People, communication, understanding. Nobody wants software – they want what it does. DDD gives us agreed approaches to solving problems
- Domains have Terminology, Natural language & Domain terms
- Meaning in difference, or it’s just ambiguity. Not repository, database, network layer, Hibernate, Singleton, Delegate (weasel words: how we solve problems, not what the problem is)
- Get rid of all primitives. Create your own primitives like year. Name isn’t a string. It is a first name and a surname, not null. Always in a valid state. Technology follows the requirements not the other way around.
- Not all domains need the same level of DDD modelling.
- If they say only black and white, ask about grey. Don’t meet in opposition.
- Collaboration not opposition, lightweight, fun
- It’s worth the effort because we have aligned our business domain and software.
- Call up Alain