DDS - Bounded Context Canvas and Capabilities
The Bounded Context Canvas fits into strategy and execution by helping to develop a shared understanding of a system and its business context we are building. This shared understanding is essential for developing a successful strategy and for executing on that strategy. The canvas can also be used to identify potential risks and challenges early in the development process. This can help teams to mitigate these risks and challenges and to deliver successful programs of change.
There are a number of resources available to help you get started with the Bounded Context Canvas. Nick Tune and Eric Evans created the original canvas, and you can find more information about it on Nick Tune’s blog https://medium.com/nick-tune-tech-strategy-blog/bounded-context-canvas-v2-simplifications-and-additions-229ed35f825f. There are also a number of commercial tools available that can help you to use the Bounded Context Canvas, such as Domainlanguage.com https://www.domainlanguage.com/.
Bounded Context, Domains and Capabilities
A bounded context in DDD is a way to carve out a specific portion of a larger business domain. It defines a boundary within which a particular domain model applies. This means that terms, concepts, and relationships within that bounded context have a specific, well-defined meaning that might differ from their use in other parts of the system.
Bounded Context and Coupling
Bounded contexts provide an opportunity to connect domain concepts in their natural coupling levels. Many domain entities are tightly bound conceptually and at run-time. If significant development-time decoupling is added within a bounded context it should be with signficant design and thought as adding too much decoupling between bounded domain concepts will ultimately create both complexity and bottlenecks. (this definitely needs more research and discussion).
Domains
The Domain is the core of Domain-Driven Design and is critical in partitioning systems. These are the nouns of the business area: orders, Payments, and Employees. However, the missing connection is between capabilities and domain concepts.
Business Capabilities Map an Organization's Activities
Business capabilities essentially describe what an organization does, not how it does it. These are verb/noun combinations focused on functional and operational divisions. They are usually high-level, stable functionalities that provide value to the business. Examples of business capabilities might be:
Alignment: Finding the Sweet Spot
The real power of understanding the relationship between bounded contexts and business capabilities lies in their alignment:
Why This Relationship Matters
How to Use This Canvas
I will continue to work with Microservices leaders and DDD experts to help us extract the best thinking related to domains, entities, service granularity and patterns applied. I am looking for anyone who wants to help discuss, document and store these methods in the BTABoK so that we can have a central store of architecture practice knowledge maintained by architects! Reach out to me if you are interested.
Next up in this Series:
For more of this join the Iasa mission to create a real profession at www.iasaglobal.org!
Enterprise Architect and Computational Social Science
11 小时前In terms of programming I think highly of the DDD work of Evans. Nick Tune is also a very well respected software developer. They are not business people. In business what an organization does is called functions. It has been that way since the beginning of the industrial age. Capabilities can be best explained in https://people.ischool.berkeley.edu/~duguid/articles/Richardson.pdf. Paul Duguid along with John Seeley Brown wrote https://en.wikipedia.org/wiki/The_Social_Life_of_Information one of the top books written in information management. This follows the idea that business capabilities are the UNIQUE things that a business does. David Teece might even get the Nobel Prize soon for showing how firms use dynamic capabilities to reconfigure the enterprise to uniquely face competitive threats. In 1972 the accountants tried the same thing to gain control over business. After this mistake in definition cost the US their manufacturing advantage https://onlinelibrary.wiley.com/doi/abs/10.1111/j.1745-6622.1992.tb00491.x the result of which started the decline of CPA's in favor of MBA's as CFO.
Co-author of Collaborative Software Design: How to facilitate domain modeling decisions. Independent consultant & trainer in technical leadership, software architecture, and #sociotechnical systems design.
15 小时前You can find, and help improve the canvas at the ddd-crew github: https://github.com/ddd-crew/bounded-context-canvas