在网络化世界强起来（思想纵横）

Question

When a single physical entity means different things in different contexts, DDD principles recommend creating different entities in each bounded context.

This is an example taken from the book "Patterns, principles and practices of Domain-Driven Design": A "Product" is a concept that must be acquired with a profitable margin and an acceptable lead time to the Procurement team. Yet to the Sales team a product is a concept with images, size, guides, and belongs to a selling category—none of which are relevant to the Procurement team, even though it is the same physical entity in the problem domain.

My question is, how does the Sales bounded context and the Procurement bounded context know they are dealing with the same product? How do you find the same entity in the Sales context and Procurement context for reporting purposes?

How do you store the identity in the database? I expect each Product class to have it's own table. Normally identity is autogenerated by the database. We can't guarantee Sales database and Procurement database would generate the same Id for the same physical entity. How do you link these two concepts in software?

Answer 1

From what you wrote, I guess you already on the right track: one needs to give products a unique ID as a common attribute, which is transferred from one bounded context to another.

Now there a couple of options how to implement this approach. Which one to choose depends mainly how the "bounded contexts" interact with each other and how your system architecture looks like.

Typically, there is one specific bounded context where Products arrive first in the system, maybe the Procurement context, maybe the Sales context, maybe a third one. There, the unique ID ist generated intially, maybe the product gets also a name or other basic attributes. Sooner or later, the other bounded contexts will be informed about the newly arrived products, either synchronously or asynchronously within certain time intervals, and there will be a synchronization process which transfers the information about the new products to any other context which needs to know about them - including the unique ID.

How this sync process looks in detail depends heavily on your specific system. I have seen systems using events to get other subsystems up-to-date within miliseconds. I have seens systems which run a nightly synchronisation routine to update subsystems within 24 hours. And I have also seen systems where an operator had to enter information from one system into another completely manually (probably together with a lot of other subsystem specific information which cannot be created automatically).

Normally identity is autogenerated by the database.

That may be normal when you have a system which contains only one, single database and only one Product table, but not in the kind of system scetched beforehand. When one bounded context creates the identity for certain records, so the identity information is transferred to other bounded contexts, only the first bounded context can use autogeneration, but not the depending subsystems. An alternative implementation could distinguish between autogenerated surrogate keys (which only provide "local identity" in each subsystem) and "domain keys" (which provide identity across different bounded contexts). This might look a little bit wasteful at a first glance, but today memory is cheap and since all these keys are immutable values, there is normally no issue with redundancy.

Answer 2

Indeed, if something has a different meaning in different bounded contexts, we'd end up with distinct entities in different bounded contexts.

There are however several ways to organise the mapping between the contexts. For example:

• Related elements can perfectly be managed in both contexts in a joint manner (shared kernel). If it appears that two entities are in reality one and the same, it is perfectly possible to share the entity between the two models.

• Elements can be managed independently in each context, but a relationship between the two established (directly, or using an anticorruption layer). Entities would then be distinct and related one-to-one. Each should then have its own identity, but it is possible in practice to use the same identifier, especially if the item in one of the context is always created before the dependent one in the other context. Example: if a purchased product would always created after the sold product because buying would first require the specification of what is to be sold.

However, I'd call for extreme caution when establishing such cross-boundaries mappings. Indeed, in my experience, the one-to-one is rather exceptional. High tech products often have one sales product definition (described in the marketing catalogue), but in reality correspond to different products manufactured or bought (slightly different configuration while the key product attributes remain the same). This is also the case for cars, where the commercial car model corresponds to several vehicle descriptors in the VIN). I also have worked in some areas that are the opposite, i.e. the same bought product is sold under two references (e.g. the same appliance repair component might be sold with two different references, each corresponding to a different appliance brand). Premature merging of entities is like premature optimisation, the root of all evil.

Answer 3

Before we get to DDD, if we consider simple data normalization, you already get to a point where you start identifying the needs for a shared root identity: the product.

On the premise that not every product has a 1-1 relationship with every department, it already leads to a three table solution:

In simple database terms: you create a product, which in turn generates an identity (PK) for that product, and then both Sales and Procurement can reference (FK) that product (PK). The product table contains all product-specific (shared) information, the other two tables contain the information that is relevant only to that department.

It is possible that your application does not reveal the product on its own. You could, if you were so inclined, create the UX in a way that the Sales and Procurement teams on their own pages are given the option to reference an existing product or trigger a new product to be created.
The question on what data you would want to store on the product to help identify them and assist teams in finding existing products is an exercise left to the reader.

In DDD terms, this creates a third bounded context: the product. As I mentioned before, whether or not the product is exposed as a separate bounded context to the outside world is a separate consideration. I would personally default to creating a dedicated Product CRUD API, but this can be avoided if there are valid justifications for doing so.

Sidenote:
In a world where you hide the product creation into the Sales/Procurement bounded contexts, I would prepare for scenarios where both departments ended up creating different identities for what they (retroactively) understand should have been the same product, and provide some kind of tooling to help identify and merge these scenarios.

---

We can't guarantee Sales database and Procurement database would generate the same Id for the same physical entity.

You shouldn't at the same time acknowledge that a product is the same identity and then plan to store it in a distributed fashion across two otherwise unrelated databases. For the same reason that you are splitting the sales and procurement data store, the product should be upheld by its own data stores.

If your concern is that of a hard FK constraint in the database, that is something you have to let go of when you separate your data stores (pretty much by definition of stores being separate). In a microservice/separate bounded context world, FK "verification" (i.e. checking referential integrity) should be done service-to-service, not table-to-table.

Answer 4

Where do you draw the boundaries of these "bounded contexts"?

I would reckon that the vast majority of businesses do not consider their sales and purchasing contexts in isolation when it comes to the products they handle.

Businesses that I'm familiar with work from a common catalog of their stock-in-trade, otherwise business activity would be extremely difficult to account for or control financially, not to mention difficult for anyone to understand how to translate purchases into sales if they are not both working from a common catalog.

Again in businesses that I'm familiar with, the distinction between the purchasing and sales functions exists not because they are handling different kinds of stock, but because they are handling different external trading parties with whom the business has different relationships (that are managed in different ways) and with whom stock flows in different directions.

As well, keeping purchasing and sales staff separate reduces the overall visibility of prices and margins, and makes it somewhat more difficult for staff on either side of the divide to understand the whole network of trading relationships that supports the business (and is typically a trade secret).

The bounded context of a business is often the whole business, because although there may be specialist functions in larger businesses that can be considered locally and severally from the others, there are also many common concerns in any business, and the definition of what kind of stock is being handled is definitely a common concern.

Answer 5

If you have the same thing in two bounded contexts, then it is persisted as a single entity in the datalayer. You are just using that data to populate different classes in the code.

Does this work in practice? Sure, as long as both products have the same properties. and its just the methods you are adding it's fine, if awkward.

Would it work in their example, where one product has a whole bunch of extra properties which are themselves child classes? I can see it becoming difficult fast.