Better software architecture documentation with Domain-driven Design

Transcript

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

   Fellow at INNOQ
   

   @bitboss
   

   View Slide

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

   View Slide

3. Get my DDD book
   
   
   cheaper
   Book Voucher: 7.99 instead of (min) 9.99
   
   
   http://leanpub.com/ddd-by-example/c/speakerdeck
   

   View Slide

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
   

   View Slide

5. https://github.com/ddd-crew
   

   View Slide

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

   View Slide

7. 7
   There are many great ideas already
   out there. Don’t reinvent the wheel!
   4+1 Model by Kruchten
   

   View Slide

8. 8
   I will mainly focus on arc42 but I’ll also
   draw some parallels to the C4 diagrams
   4+1 Model by Kruchten
   

   View Slide

9. 9
   However, we have an issue:
   
   
   Most documentation is done by software
   architects „alone in their chambers“
   

   View Slide

10. 10
    Often this kind of documentation is
    hard to grasp for other stakeholders
    
    Architect Documentation
    
    Other stakeholders
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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

    View Slide

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

    View Slide

15. View Slide

16. Ideas from the Business
    Model Canvas are a great
    input into the
    f
    irst chapter
    of the ARC42 template
    

    View Slide

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

    View Slide

18. <

    Design community>>
    
    
    Event Storming
    <

    Design community>>
    
    
    Domain Storytelling
    18
    Popular Collaborative Modelling Techniques
    <Development community>>
    
    
    Example Mapping
    <community>>
    
    
    User Story Mapping
    

    View Slide

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
    

    View Slide

20. Chaotic Exploration
    

    View Slide

21. Enforcing the timeline
    

    View Slide

22. Pivotal Events & Swimlanes
    

    View Slide

23. External Systems
    

    View Slide

24. Actors & Commands
    

    View Slide

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

    View Slide

26. Arc42
    
    
    Business Scope & Context
    C4 Model
    
    
    Level 1: System Context Diagram
    Source: https://c4model.com/
    Source: https://arc42.org/overview
    

    View Slide

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
    

    View Slide

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!
    

    View Slide

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

    View Slide

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
    

    View Slide

31. 31
    There are many modeling choices to
    group domain concepts
    

    View Slide

32. 32
    „All models are wrong, but some are useful“
    
    
    Quote by George E. P. Box
    Thing Color Process
    

    View Slide

33. Boundaries between Pivotal Events
    

    View Slide

34. Mind the swimlanes
    

    View Slide

35. Look for terminology
    

    View Slide

36. View Slide

37. Arc42
    
    
    Building Block View
    C4 Model
    
    
    Level 2: Container Diagram
    
    
    (in parts)
    Source: https://c4model.com/
    Source: https://arc42.org/overview
    

    View Slide

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
    

    View Slide

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

    View Slide

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
    

    View Slide

41. View Slide

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
    

    View Slide

43. The Ubiquitous Languge and parts of the Business
    Decisions should be a key element of the glossary
    

    View Slide

44. View Slide

45. How do we get the In- and Outbound Communication?
    

    View Slide

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

    View Slide

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
    

    View Slide

48. View Slide

49. Domain Message
    f
    lows are
    
    
    a good 1st
    f
    it for the arc42
    
    
    runtime view
    
    
    

    View Slide

50. They can
    also be easily
    transformed
    towards the
    dynamic
    diagram of
    the C4 Model
    
    
    Image Source: https://c4model.com/
    

    View Slide

51. 51
    One more thing….
    
    
    Think about chapter 10 of the arc42
    template: quality requirements
    
    
    Aren’t they hard to obtain from your
    stakeholders?
    

    View Slide

52. prioritization
    consolidation
    broad collection
    preparation
    Quality Storming
    

    View Slide

53. The end result of a
    

    Quality Storming Workshop:
    
    
    A set of prioritized quality requirements
    

    View Slide

54. Read the full
    
    
    description on
    
    
    innoq.com
    
    
    (in English and German)
    https://www.innoq.com/en/articles/2020/02/quality-storming-workshop/
    

    View Slide

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
    

    View Slide

56. Get my DDD book
    
    
    cheaper
    Book Voucher: 7.99 instead of (min) 9.99
    
    
    http://leanpub.com/ddd-by-example/c/speakerdeck
    

    View Slide

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
    

    View Slide