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

Michael Plöd

January 27, 2021
Tweet

More Decks by Michael Plöd

Other Decks in Programming

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