ddd-crew / bounded-context-canvas Goto Github PK

There are two templates to update:

• miroversum
• backup file as the resource (done by @mploed already)

The first one can only be done by @NTCoding. Would you update it, or do you have another suggestion?
Maybe you (as hero@miro 😉) could create a ddd-crew account for miroverse (no idea if it is possible), and invite others from the @ddd-crew so that this job can be scaled better 🤔

Hi @NTCoding,
do you plan releasing a Miro Template for the new version or are you even working on one?

Best regards,
Michael

The current canvas in v4 contains the following collaborator types:

• Bounded Context
• External System
• Frontend

This may imply that the frontend is not part of a bounded context. This is the case when there is a separate frontend (system and/or team) and I think it is a correct collaborator type.

However, when you model bounded contexts with the idead behind Self-contained Systems (see https://scs-architecture.org/ ) in mind this may not be the way to model these aspects because a SCS provides its own frontend or frontend widgets. In this context I see the frontend as part of the implementation of a bounded context and I would rather see a user persona or role as a collaborator.

What is your take on that?

Hi!
I'm new to DDD and would like to know more about the terms core, supporting and generic domains. What exactly is meant by "key strategic initiative" and "differentiator"? How can you tell what category a certain domain belongs to?
Thanks

The canvas has some new (and very valuable) content which needs to be translated in French: #28

Thank you 👍

One of the topics that frequently comes up is around the flow of messages and dependencies. The canvas can be improved in this aspect.

People like Vaughn Vernon have also mentioned that the canvas could show flow more. After leaving this on the backburner it now seems like the right way to go, and it will make the canvas clearer and almost self-documenting.

Messages flow in, business decisions are applied expressed in ubiquitous language, and messages go out.

So here's what I'm thinking:

I don't this is 100% perfect, but I think it's an improvement.

Feedback and alternative proposals are always good. I've also started a twitter thread requesting feedback: https://twitter.com/ntcoding/status/1274243753440620544?s=20

Currently the HTML version requires a browser extension for saving, which seems like a significant hurdle. This probably isn't necessary though: There are now standardized APIs for accessing the file system from JavaScript.

I have a simplistic demo demonstrating that. It uses the aforementioned APIs where available or generates a download link for other browsers, TiddlyWiki-style. (Indeed, the latter might be sufficient in this case.)

The first line of the readme says "A bounded context is a sub-system in a software architecture aligned to a part of your domain."

This is literally the opposite of what it is.

A Bounded Context is a boundary around a model and its language. Within this boundary, the meaning of terms is unambiguous, well-defined and understood. The model is clear and the rules are consistent. It offers no such guarantees outside of its boundary.

• It's not a subsystem, it might be spread across multiple subsystems. It might not have a physical system, such as an Interchange context.
• It might span multiple domains or only deal with a chunk of a single domain.
• A domain might be expressed in multiple bounded contexts, eg if we purchase a competitor that does similar activities.

This incorrect reasoning lies at the heart of the whole BC canvas and is probably responsible for a lot of misunderstanding in the DDD community.

Hi all,

I have been using the Bounded Context Canvas (v2 and v3) a couple of times now. I wanted to ask the opinion of author(s) and other practitioners on (1) design vs. documentation and (2) differentiation between canvas and context map:

(1) Do you (authors and community) use the canvas primarily as a design tool or as a documentation template?

In Nick’s original post, filling out the canvas is part of a “design recipe”. In my practice as a facilitator, I mostly use the canvas as my personal “checklist”: I have the teams work out name, description, UL, relevant actors etc. while we go through the modeled scenarios. We capture everything on sticky notes while discussing candidate bounded contexts. The canvas itself is then used to document the findings. In one case, we used the Miro template. In three other cases, the teams preferred Confluence for documentation. The segments of the canvas became sections of the confluence page.

(2) Do you (authors and community) have recommendations how to deal with the overlap between the canvas and context maps?

The canvas (v4) segments “inbound communication” and “outbound communication” describe relationships between bounded contexts that could also be depicted in a context map. Since I don’t like to document the same information in two places, I usually leave everything blank in the canvas that can be put in a context map.

Thanks in advance four your opinions!

Stefan

In the current (and proposed next version) of the bounded context design canvas is an inconsistency between the examples in the domain roles section and the model traits worksheet.

The examples in the domain roles section mention an analysis context, however it is not described in the model traits worksheet what that actually is. The analysis context is also not mentioned in th blog by Alberto (is the linked one even the right one?) and the presentation by Rebecca.

We should either remote the analysis context from the examples or add it to the model traits worksheet.

Hi,
Altough it's clear, i'd find it really helpful to have a concrete example of a real world use case, for example the billing side of a an e-commerce website.
A filled-in canvas should be self sufficient
What do you think ?

The file instructions.md was renamed, but the references to it weren't changed. (Pro tip: webstorm shows errors like this 😉 )

I didn't find a draw.io template for version 4. I think someone has already one and just needs to upload it. If not, I'll volunteer.

Hello friends!

I want to suggest to add at least a stakeholder field to the canvas. I find it important, also for software architecture, to know who the stakeholders are. These can of course be the users (Specified) that interact with the model, but also departments in the organisation that have certain needs they need to see fulfilled.

For instance, for a cinema, you can model the bounded context called movie screening seat allocation. Who has the stakeholder which is a movie visitor that want to select seats. Then we might also have finance who's needs is it to fully fill the cinema as much as possible. But at some points during corona you also have legal that had certain needs to the context.

Now the more stakeholders on a context can signal that the context might be to big as wel!

Now all can be described right now in the purpose, but I would like to make it explicit in the canvas, including the needs.
Here an example of how it might look like, but first let;s discuss if it is needed!

I'm looking for input before embarking in the journey to find or create a nice way to capture BC canvas information in a structured format.

The goal is to have an RFC like process to change BCs in a domain, where feedback can be gathered, changes suggested etc. Intention is for the process to be running on GitHub via PRs, which could use actions to render the structured format into an SVG or other visual format.

Questions

• Knowledge of any "prior art"?
• What would be a suitable file format? (YAML, JSON, something else)
• Could also be a DSL inspired by Structurizr?

Right now, we are using clouds to visualize a bounded context. We say it is an explicit boundary, but clouds represent fuzziness.

I started using squircles (rectangle with round corners) to represent BC's because I feel this fits better with what a bounded context is. (well defined, but at the boundaries still a bit rounded sometimes)
Any objections to this change?

As people know I am a huge fan of Example Mapping and using the acceptance criteria as another perspective on the business rules. Business Rule might be highly ambigious and it is usually until we see Examples that it makes more sense.

That is why I want to propose is to add Examples as Acceptance Criteria to the board, preferably under the Business Decisions section, or blended in the business Decisions. Every Business Decision should have some Examples underneath them like you would do in an Example Mapping session.

I have previously written about it here:
https://baasie.com/2020/03/09/extending-the-bounded-context-canvas-with-bdd-examples/

In https://github.com/ddd-crew/bounded-context-canvas?tab=readme-ov-file the link to Bounded Context Archetypes does no longer work.

In recent workshops with customers I often renamed the Description field of the canvas to "Purpose" following some content seen in the DDD community like:

"A Bounded Context is a boundary for a model expressed in a consistent ubiquitous language tailored around a specific purpose"

or
"A Bounded Context is a unit of Autonomy, Mastery and Purpose" (from one of Alberto's presentations)

I like making the purpose very explicit because "Description" can be interpreted as something very vague.

What do you think?