4

In my organization we're trying to design our microservices based on the Bounded Context (BC) pattern (part of Domain-driven design). While we're doing this we also try to use another DDD pattern called the Context Mapping, to better identify the various contexts in the application, their boundaries and the relations between them.

All of this can be done on a whiteboard or in some online drawing tool. However, I'm looking for a way to generate a complete picture of the various services, what aggregates they contain and potentially the relations between such aggregates (as the same User in one BC might be a Customer in another). A good example is figure 4-10 in here. The generation should ideally be based on some DSL or script which we would maintain, as this kind of work is fairly high-level and context boundaries don't change very often. For example, a team adds a new aggregate or starts keeping a copy of an aggregate from another service, they update the script/DSL and regenerate the diagram.

Solutions I've looked at so far:

  • Context mapper - it doesn't visualise the aggregates in each BC/service, nor does it show relations
  • C4 model, Level 2 - we already use it, so it could be fairly easy to add a textual list of aggregates per container, but it's not what it's intended for (and the visualisation is not optimal)
  • ddd bounded context/microservice canvas - it's too detailed and can't really be used to look at the big picture

I'm wondering how and if this is done in other organization, and looking for suggestions for some tooling that would be of help.

Milan Milanov
  • 412
  • 1
  • 8
  • 27

1 Answers1

0

I think the format used for event storming sessions might be worth to have look at in your case. Once done it covers all domain events, commands, actors, read models, policies, external systems. Also it illustrates the bounded contexts in which the aggregates, events, etc. live in. An example can be found here: https://medium.com/capital-one-tech/event-storming-decomposing-the-monolith-to-kick-start-your-microservice-architecture-acb8695a6e61

I know the format is mainly used for domain exploration but from my experience, if done nicely (e.g. using some tool like Miro, Lucid, or the like) it also provides good documentation and overview of what's going on in your system.

Andreas Hütter
  • 3,288
  • 1
  • 11
  • 19
  • We've done event storming, and it is indeed helpful. However, I'm looking for a way to generate that diagram (by code/dsl), instead of it living in a separate place (Miro, Lucid, etc). Documentation should ideally live near the codebase. – Milan Milanov May 05 '22 at 10:26
  • 1
    Understood, can you update that in your question? That you are looking for something to be generated from code? I also think that code read so well that ideally no extra documentation is needed... – Andreas Hütter May 05 '22 at 16:02
  • 1
    It would also be interesting: who is the main audience of these docs? – Andreas Hütter May 05 '22 at 16:04
  • Not from code, *by* code (eg by a script or a DSL). Service owners would maintain these scripts/dsls up to date. The primary audience would be the various teams that own the services (during tech discussions), as well as new team members. – Milan Milanov May 06 '22 at 09:15