DDS - Bounded Context Canvas and Capabilities

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.


https://iasa-global.github.io/btabok/bounded_context_canvas.html

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:

  • Customer Relationship Management (CRM)
  • Order Fulfillment
  • Inventory Management
  • Payment Processing

Alignment: Finding the Sweet Spot

The real power of understanding the relationship between bounded contexts and business capabilities lies in their alignment:

  • Identifying Bounded Contexts: Business capabilities can be a starting point for the discovery and definition of bounded contexts. Analyzing the distinct activities and responsibilities within a business capability can point towards natural divisions where separate, focused domain models might make sense.
  • Context Size: Sometimes, a bounded context might directly encapsulate a single business capability. Other times, a business capability might be complex enough to be composed of several related bounded contexts.
  • Evolving Together: Ideally, bounded contexts and business capabilities inform each other and evolve in tandem. Changes in how a business operates should be reflected in the capabilities it defines, and this will likely influence the models within your bounded contexts.

Why This Relationship Matters

  1. Reduced Complexity: Breaking down a complex business domain into bounded contexts aligned with capabilities makes the system easier to understand, design, build, and maintain. Teams can focus on a smaller, more manageable domain.
  2. Clear Communication: Explicitly aligning business terms with the concepts in bounded contexts creates a common language, improving communication between development teams and business stakeholders.
  3. Adaptability: As a business's needs and capabilities change, bounded contexts that reflect those capabilities provide natural points for the software system to evolve and adapt as well.

How to Use This Canvas

  1. Assemble your team.?The Bounded Context Canvas like the entire Structured Canvas Approach (tm) is a collaborative tool, so it is important to get all of the stakeholders involved in the bounded context together to work on it. This could include developers, business analysts, domain experts, and product managers.
  2. Fill out the canvas.?The canvas is divided into several sections, each of which prompts you to enter information about the bounded context. The specific sections may vary slightly depending on the version of the canvas you are using, but they typically include:
  3. Discuss and refine.?As you fill out the canvas, discuss each section with the team and come to a consensus on the information that you enter. This is a great opportunity to identify any areas of disagreement or uncertainty.
  4. Use the canvas to guide your design and implementation.?Once you have completed the Bounded Context Canvas, you can use it to guide your design and implementation of the bounded context. The information on the canvas will help you to make decisions about the architecture, technology stack, and APIs of the bounded context.

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:

  • DDD and Teams - How can the architect help structure deployment/service teams and how do those relate to business architecture and solution architecture. This is very edgy stuff!
  • Coupling and Patterns in DDS - how do we remove dev decoupling while retaining appropriate pattern utilization
  • Value Themes and Domain Teams - how do we understand value related to business capability measures, objectives and team work product

For more of this join the Iasa mission to create a real profession at www.iasaglobal.org!


Mark Goetsch MSCS, MSC

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.

Kenny Baas-Schwegler

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

回复

要查看或添加评论,请登录

Paul Preiss的更多文章

  • Domain-Driven Services - Just the Right Size

    Domain-Driven Services - Just the Right Size

    Microservices were too small, SOA was too big. DDS is juuuuust right.

    16 条评论
  • Time to Take a Breath

    Time to Take a Breath

    The outcomes of the Paris discussions on AI were less than exhilarating at least politically. The general trend of AI…

    3 条评论
  • Deep Learning

    Deep Learning

    As the age of technology continues to explode, it is essential that we do not gloss over the amount of learning and…

    4 条评论
  • We All Love Our Toys

    We All Love Our Toys

    When I was a boy I loved legos, as so many architects and engineers did. It was a deeply calming and deeply engaging…

    21 条评论
  • Navigating Hope and Fear in a Socio-Technical Future

    Navigating Hope and Fear in a Socio-Technical Future

    I was just finishing doing a talk on Living with Legacy, which covers a great number of concepts related to…

    22 条评论
  • You Can't Wish Away Technology Complexity

    You Can't Wish Away Technology Complexity

    I attend a great number of architectural discussions at all levels of scope. And it is a constant reminder how much…

    32 条评论
  • The Case For A Managed Career for Architects

    The Case For A Managed Career for Architects

    The question of career path is deeply important to architects. It determines many of the qualities which allow them to…

    26 条评论
  • Architect's Competing Narratives

    Architect's Competing Narratives

    I want to open us up to a conversation about narratives in architecture. These are deeply important to us as architects…

    10 条评论
  • AI and Architecture

    AI and Architecture

    We hear so much about AI these days. In my position holding events, running training, helping organisations build solid…

    12 条评论
  • Chasing the Tech in Architect

    Chasing the Tech in Architect

    The last year I have been working to deeply refresh my understanding of implementation trends again. Microservices…

    4 条评论