Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Better software architecture documentation with Domain-driven Design

Better software architecture documentation with Domain-driven Design

21a532a137b506128914478ac521fc8b?s=128

Michael Plöd

January 27, 2021
Tweet

Transcript

  1. Getting a better software architecture documentation with Domain-driven Design Michael

    Plöd 
 Fellow at INNOQ 
 @bitboss
  2. 2 Speaker Michael Plöd Fellow at INNOQ Twitter: @bitboss

  3. Get my DDD book cheaper Book Voucher: 7.99 instead of

    (min) 9.99 http://leanpub.com/ddd-by-example/c/speakerdeck
  4. 4 I need to send a bunch of huge props

    to those folks who heavily inspired a lot of content in this talk Simon Brown Alberto Brandolini Nick Tune Kacper Gunia Gernot Starke Indu Alagarsamy …. and of course Eric Evans …. Many INNOQ folks (of course ;-) ) Krisztina Hirth Peter Hruschka
  5. https://github.com/ddd-crew

  6. 6 Let’s talk about documentation of software architecture f irst

  7. 7 There are many great ideas already out there. Don’t

    reinvent the wheel! 4+1 Model by Kruchten
  8. 8 I will mainly focus on arc42 but I’ll also

    draw some parallels to the C4 diagrams 4+1 Model by Kruchten
  9. 9 However, we have an issue: Most documentation is done

    by software architects „alone in their chambers“
  10. 10 Often this kind of documentation is hard to grasp

    for other stakeholders Architect Documentation Other stakeholders
  11. There is help •DDD is all about collaboration between domain

    experts and software engineering teams •DDD has concepts like the Bounded Context that may come in handy •With the help of some ideas of Domain-driven Design we will be able to create better documentation for our software architectures Domain Driven Design 11
  12. „It is not the domain experts knowledge that goes into

    production, it is the assumption of the developers that goes into production” 12 Alberto Brandolini Inventor of EventStorming
  13. 13 https://github.com/ddd-crew/ddd-starter-modelling-process

  14. 14 https://github.com/ddd-crew/ddd-starter-modelling-process

  15. None
  16. Ideas from the Business Model Canvas are a great input

    into the f irst chapter of the ARC42 template
  17. 17 https://github.com/ddd-crew/ddd-starter-modelling-process

  18. <<from the Domain-driven 
 Design community>> Event Storming <<from the

    Domain-driven 
 Design community>> Domain Storytelling 18 Popular Collaborative Modelling Techniques <<from the Behavior-driven Development community>> Example Mapping <<from the agile product design community>> User Story Mapping
  19. 19 Event Storming Event Storming is based events which happen

    in a problem domain and which are interesting for domain experts. They are written in past tense on orange sticky notes
  20. Chaotic Exploration

  21. Enforcing the timeline

  22. Pivotal Events & Swimlanes

  23. External Systems

  24. Actors & Commands

  25. This state of an EventStorming can directly be merged to

    your documentation
  26. Arc42 Business Scope & Context C4 Model Level 1: System

    Context Diagram Source: https://c4model.com/ Source: https://arc42.org/overview
  27. From EventStorming • External Systems (pink stickies): candidates for software

    systems to integrate with • Actors (yellow stickies): People, user roles • Commands (blue stickies) or Events (orange stickies): actions by actors or integration towards software systems
  28. 28 The context views in many software architecture documentation templates

    is often underestimated but it contains a lot of politics sometimes. It helps a lot to create an early and shared understanding. EventStorming helps!
  29. 29 https://github.com/ddd-crew/ddd-starter-modelling-process

  30. 30 A Bounded Context is… • A boundary for a

    model expressed in a consistent ubiquitous language tailored around a speci f ic purpose • A unit of: • Autonomy • Mastery • Purpose • A safe space for: • Learning domain complexity • Experimenting • Delivering high value software • A team f irst boundary This slide contains ideas from the DDD book by Eric Evans, from Alberto Brandolini and from the Team Topologies book by Mathew Skelton and Manuel Pais
  31. 31 There are many modeling choices to group domain concepts

  32. 32 „All models are wrong, but some are useful“ Quote

    by George E. P. Box Thing Color Process
  33. Boundaries between Pivotal Events

  34. Mind the swimlanes

  35. Look for terminology

  36. None
  37. Arc42 Building Block View C4 Model Level 2: Container Diagram

    (in parts) Source: https://c4model.com/ Source: https://arc42.org/overview
  38. 38 Bounded Contexts are great candidates for the 1st level

    of the building block view in arc42. If you go for self-contained systems, they can also be good candidates for the container diagram in the C4 Model EventStorming helps in discussing „domain- driven software modules“ with the business in a collaborative way
  39. 39 https://github.com/ddd-crew/ddd-starter-modelling-process

  40. 40 Bounded Context Design Canvas The canvas guides you through

    the process of designing a bounded context by requiring you to consider and make choices about the key elements of its design, from naming to responsibilities, to its public interface and dependencies. Source: https://github.com/ddd-crew/bounded-context-canvas
  41. None
  42. 42 The Bounded Context Canvas, which was invented by NICK

    TUNE (great guy btw!) is not only a good helper in asking questions during the design phase it can also be your f irst bit of documentation for your building blocks. It is also a good summary for folks who are interested in getting an overview of your building blocks
  43. The Ubiquitous Languge and parts of the Business Decisions should

    be a key element of the glossary
  44. None
  45. How do we get the In- and Outbound Communication?

  46. 46 https://github.com/ddd-crew/ddd-starter-modelling-process

  47. 47 Domain Message Flow Modelling A Domain Message Flow Diagram

    is a simple visualisation showing the f low of messages (commands, events, queries) between actors, bounded contexts, and systems, for a single scenario. Source: https://github.com/ddd-crew/domain-message- f low-modelling
  48. None
  49. Domain Message f lows are a good 1st f it

    for the arc42 runtime view
  50. They can also be easily transformed towards the dynamic diagram

    of the C4 Model Image Source: https://c4model.com/
  51. 51 One more thing…. Think about chapter 10 of the

    arc42 template: quality requirements Aren’t they hard to obtain from your stakeholders?
  52. prioritization consolidation broad collection preparation Quality Storming

  53. The end result of a 
 Quality Storming Workshop: A

    set of prioritized quality requirements
  54. Read the full description on innoq.com (in English and German)

    https://www.innoq.com/en/articles/2020/02/quality-storming-workshop/
  55. Summary: Ideas and concepts behind DDD are a good f

    it for getting a better documentation and design of your software Big Picture EventStorming Bounded Contexts Domain Message Flows Quality Storming Ubiquitous Language
  56. Get my DDD book cheaper Book Voucher: 7.99 instead of

    (min) 9.99 http://leanpub.com/ddd-by-example/c/speakerdeck
  57. Krischerstr. 100 40789 Monheim am Rhein Germany +49 2173 3366-0

    Ohlauer Str. 43 10999 Berlin Germany +49 2173 3366-0 Ludwigstr. 180E 63067 Offenbach Germany +49 2173 3366-0 Kreuzstr. 16 80331 München Germany +49 2173 3366-0 Hermannstrasse 13 20095 Hamburg Germany +49 2173 3366-0 Gewerbestr. 11 CH-6330 Cham Switzerland +41 41 743 0116 innoQ Deutschland GmbH innoQ Schweiz GmbH www.innoq.com 57 Thank you! Michael Plöd 
 Follow me on Twitter: @bitboss