1. Domain Driven Design Agile SIG Talk Richard Walls

2. Domain Driven Design Domain driven design provides a bridge between the users and the development team. It creates a common, ubiquitous language. It deepens the domain knowledge of the team, allowing them to add greater value, and boot straps up new team members understanding and effectiveness. It allows whiteboard re-factoring before going to code, and cohesive direction before starting up. It provides a model to organise both the solution and the team around, and creates naturally controlled interfaces between them. It manifests itself in a clear, coherent, intuitive solution that reflects the mental model of the user. Agile doesn’t say no design, it say’s just enough. Back in my OOA/D/P days I found modelling (static and dynamic) provided a quick, cheap and insightful approach, to understanding the users requirements, in a way that everyone - users, analysts, UX designs, developments, testers - could be involved. I still use it informally when trying to grasp existing systems, or when establishing product backlogs. With the advent of Agile, modelling, whether formal or informal, seems to have gone out of fashion. At the discussion I’ll arguing for more domain driven design and exploring the boundaries of just enough on an Agile development.

3. Domain Driven Design Purpose isn’t to teach domain driven design … the purpose is to promote it … But we to need to start with a common understanding …

4. Domain Driven Design What’s the difference between a Virgin Holiday’s Customer and a Virgin Holiday’s Passenger?

5. A Domain Model Outside Inside

6. A Domain Model Outside Booking Product Customer Destination Invoice

7. Complexity Outside Booking Product Customer Destination Car Hire Cruise Hotel Holiday Attraction Ticket Passenger Address Itinerary Tickets Location Attractions Events Weather Facilities Flight Airport Airline Passport Offer Deal

8. Subdomains Outside Booking Product Customer Destination Car Hire Cruise Hotel Holiday Attraction Ticket Passenger Address Itinerary Tickets Location Attractions Events Weather Facilities Flight Airport Airline Passport Offer Deal Invoice

9. Software Modules Outside Booking Making bookings Managing bookings Fulfilling bookings Product Creating products Managing products Searching for products Taxonomy Customer Destination Managing destinations Maintaining destination details Destination searching Creating customers Maintaining customer details Managing customer contacts High Cohesion, Low Coupling

10. Formalising Static Relationships - UML BookingCustomer AddressBooking Component Invoice 11..n Flight Booking Hotel Booking 1 Passenger?

11. Behaviour ChessboardChess Pieces PieceSquare 64 16 Move PawnRook Knight Bishop Queen King 1 Occupies From To (Very) Simple Chess Static Model 0..1 1 1 2 2 2 8 Does give you any clue as to the rules of chess?

12. Behaviour Design Scenarios Scenario 1 - Move a pawn 1 square up the board Scenario 2 – Pawn move blocked Scenario 3 – Take an opposing piece with a pawn Scenario 4 – Move a pawn that puts its own King in check. Movement Rules A pawn can move 2 squares “up” the board on move 1, and 1 square on subsequent moves if the square(s) is unoccupied A pawn can move diagonally 1 square to take an opposing piece Bishop can move diagonally in any direction, on the colour of square they started on Bishop can not “jump” a square occupied by a piece of the same set A piece cannot move if it puts it’s own King in check

13. Behaviour Pawn Square Move Controller Move Move piece from a2 to a3 (1) Get Piece (a2) ^Pawn (2) Valid move (a2,a3)) ^ Success (3) Occupied? (a3) ^No (5) Record move (a2,a3)) (4) Move (a2,a3)) ^ yes Scenario 1 – move pawn up the board one square - success

14. Responsibility Driven Design (Rebecca Wirfs-Brock) Each class is represented by a CRC ( candidate, responsibility, collaboration) card Each member of the team represents a candidate class (better still its lawyer) Each scenario is role played by the team – simplest sunny case first. Product owner should be involved to participate or answer questions. The aim is not to complete every scenario! The aim is to complete just enough to determine the responsibilities and key collaborations between classes. This point will occur naturally – when the model is no longer changing! At the end everyone understands the design (hopefully) Goes someway to reduce refactoring hell ! Both the static model and class model can emerge through running through the scenarios Does this sound like BDD on a white board?

15. When to do it? Resist the temptation to dive into code! Design when it’s needed!!! If it saves time by reducing re- factoring hell than you need to find time! During the proceeding sprint? During sprint boundary (between demos, retros and sprint planning? As part of sprint planning? On the first day of the sprint? When the first story that touches an area is pulled from the sprint backlog?

16. What’s just enough? To start work on a set of related stories An informal static domain diagram on a whiteboard for the area concerned An informal collaboration diagram on a whiteboard for the area concerned CRC cards with the responsibility of the classes Anything else? For sharing understanding across teams and with new team members High level domain model showing key entities, relationships and subdomains Description of the role of each entity and what it represents – customer v passenger? Key patterns than demonstrate the key behavioral patterns – interaction diagreams rather than collaboration? These will build up over time! Someone must take responsibility for documenting! Shouldn’t replicate anything that the code can represent!

17. Practical Scenario 1 - Move a pawn 1 square up the board Scenario 2 – Pawn move blocked Scenario 3 – Take an opposing piece with a pawn Scenario 4 – Move a pawn that puts its own King in check.

18. Q&A Q&A & Wrap Up What’s the next subject?

19. Further Reading Books Domain Driven Design – Eric Evans PDF http://www.infoq.com/minibooks/domain-driven-design-quicklyhttp://www.infoq.com/minibooks/domain-driven-design-quickly - summary of the book Web http://www.typo3-media.com/blog/domain-driven-design- introduction.htmlhttp://www.typo3-media.com/blog/domain-driven-design- introduction.html - An overview of DDD http://www.mirkosertic.de/doku.php/architecturedesign/dddbuildingb lockshttp://www.mirkosertic.de/doku.php/architecturedesign/dddbuildingb locks - High level overview of DDD