Defining Bounded Contexts using Business Capabilities or Domains?

Question

I am new to Domain-Driven Design.

When I was trying to define the bounded contexts of the software, I don't know where to start.

After some searching on the Internet, I am totally confused.

Some articles recommend defining bounded contexts from the Business Capabilities since it follows the Conway's law. Here is one post: https://softwareengineering.stackexchange.com/a/358974/402592

Some said bounded contexts are defined from the Domains as it is what Domain-Driven Design means.

Which way should I follow?

Answer 1

Your Bounded Context(s) are whatever makes most sense according to the needs of your stakeholders. If your stakeholders all need the exact same thing, or their needs only vary in trivial ways, then a single Bounded Context for everything could be fine.

To identify your BCs is to understand, as far as realistically possible, what your stakeholders really need, the differences between them, and ideally how that may evolve in future, if possible.

Consider some of the following:

• Who is paying for all of this? (This person/group usually gets the final say on everything, including the overall scope of the project, the core vision, etc.)
• Who are the other stakeholders?
• What are their needs from the system?
• How closely are their needs aligned with each other?
• What priority do they get over other stakeholders, if any?

Remember that needs and therefore variations could derive from many sources:

• Core purpose of the business
• Separate Business functions
• Legal issues (privacy, industry governance, standards compliance, contracts, etc.)
• Geography/Culture (variations due to location/language/social convention/etc.)
• Bespoke demands from customers/clients
• Corporate structure and governance (e.g. collaboration between different people and teams within the business, future restructuring, reassignment of responsibilities between people/teams, etc)
• Partnerships (e.g. collaboration with external/3rd parties)

Stakeholder needs may involve variations on a single concept; it's a judgement call as to whether that single concept is part of a single Bounded Context or whether it should be represented in different ways for multiple Bounded Contexts.

For example, consider a Sales team generating a Customer Order for Warehouse pickers; the extent to which these cross-over will depend a lot on the business operating model.

There are obvious similarities; both will need to know the product is in-stock, and both will need the customer's delivery address, but the teams perform fundamentally different job functions. Simply identifying some overlap is not necessarily enough to be able to know whether you need a single Bounded Context for Order Processing, or separate ones for Sales and Warehousing

The only way you can decide which way to jump is to start conversations with both to understand out how similar or different their needs.

Having stakeholders talking physically in the same meeting (or call) can often reveal whether they could work with a single unified model, or whether they are so far apart that their needs are likely to diverge in wildly different directions.

The Warehouse team may not care how much the customer paid for the order, the Sales team may not care which palette in the warehouse the order needs to be picked from.

If the Warehouse team's idea of a useful Customer Order system and business rules surrounding it are wildly different from those of the Salespeople, then it might be easier to just treat Sales and Warehouse as separate domains, accepting the need for a layer of complexity which handles translation between them.

Yet the one constant is change; the business could decide one day to make the Sales team responsible for picking and shipping orders in the Warehouse; with two separate models that should be OK - the Sales team just need to learn to how the Warehouse model works.

It'd be harder the other way around however; if you had one model and the business then decides to split and move affected people/teams in different directions (or worse, sell/outsource a business function to another company), the developers could suddenly end up needing to fudge competing, contradictory requirements into the model.

For that reason, some might consider it safer in the long-term to lean toward a greater number of smaller Bounded Contexts, but this extra complexity nearly always has additional costs in development, maintenance, testing, architecture, infrastructure, live support, etc.

The bottom line is that you need to fully analyse and understand your requirements and the people who are affected by the systems; Even two different businesses who appear to work in the same domain(s) may arrive at fundamentally different conclusions about how to divide everything.

Whatever you do, you will never be able to predict everything about the future, so don't just rely on DDD for a maintainable design; one day your domain model will probably be wrong, but you won't know that while you're trying to design it.

Answer 2

For me this is pretty simple. Forget about all the "guidelines" and design philosophy and think about what you are making and how finely it can be split up and still function.

For example an e-commerce business.

• Can I split the warehouse apps from the shop front apps?
• Can I split the payment taking app from the ordering app?
• Can I split the price from the product?

The answers to these questions will depend on the exact features you have to write, your choice of architecture and your own ability/experience/inventiveness.

Usually in software the best practice is always to break stuff up into smaller units.

Some of the big choices might be obvious. Maybe half your goods are outsourced to someone else's warehouse, then that's a forced split and you might as well carry it over to your warehouse.

Some might be hard to see how you would make it work, I need to show the price to the customer when they select the products, how can I split that off? Well if you can't see how to do it, and you are the one doing it, maybe not doing it is the best solution for now!

Each split comes with overhead and problems to solve, so its a trade off which can really only be judged at the time by the person doing it.