Better software architecture documentation with Domain-driven Design

Slide 1

Slide 1 text

Getting a better software architecture documentation with Domain-driven Design Michael Plöd   Fellow at INNOQ   @bitboss

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

https://github.com/ddd-crew

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

„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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

No content

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

<> Event Storming <> Domain Storytelling 18 Popular Collaborative Modelling Techniques <> Example Mapping <> User Story Mapping

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

Chaotic Exploration

Slide 21

Slide 21 text

Enforcing the timeline

Slide 22

Slide 22 text

Pivotal Events & Swimlanes

Slide 23

Slide 23 text

External Systems

Slide 24

Slide 24 text

Actors & Commands

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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!

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

31 There are many modeling choices to group domain concepts

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

Boundaries between Pivotal Events

Slide 34

Slide 34 text

Mind the swimlanes

Slide 35

Slide 35 text

Look for terminology

Slide 36

Slide 36 text

No content

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

No content

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

No content

Slide 45

Slide 45 text

How do we get the In- and Outbound Communication?

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

No content

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

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

Slide 52

Slide 52 text

prioritization consolidation broad collection preparation Quality Storming

Slide 53

Slide 53 text

The end result of a   Quality Storming Workshop: A set of prioritized quality requirements

Slide 54

Slide 54 text

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

Slide 55

Slide 55 text

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

Slide 56

Slide 56 text

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

Slide 57

Slide 57 text

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