What's wrong with multiple entities in multiple bounded contexts pointing to the same identity?

Question

Following this answer from different question I've been somewhat shocked with the following statement:

An aggregate in one BC would be represented either by an id or as a value object in another BC. Only a single BC should be the system of record of any aggregate.

What I do agree with, is the fact, that only one BC should be the owner of the given identity (the initiator of that identity presence in the whole system). But what is confusing to me, is the statement, that every other BC should represent the same concept only as a read only value object with just the subset of the attributes of the entity from BC that owns the given identity (no extra attributes related to consuming BC).

Using a Customer as an example, what's wrong with representing it as an entity in multiple BCs with different attributes in each BC (especially, when there's some BC related, user editable config, which wouldn't make sense in another BC at all), but sharing the same identity? I tought, that this is the essence of the bounded context definition - to represent the same concept (same real world identity) in different domains with the behavior and attributes only related to that given domain. Am I missing something? Is it better to use single BC for CustomersManagement with all possible attributes (user editable config) that all other BCs could use?

Answer 1

I may be stating some obvious bits here, but please bear with me as I put it all together.

The following statement refers only to the aggregate itself, not the identity:

An aggregate in one BC would be represented either by an id or as a value object in another BC. Only a single BC should be the system of record of any aggregate.

The main concept here is that a particular aggregate root has a single system of record. This idea isn't unique to domain-driven design. Traditionally, a database record would also only have a single source of truth.

When it comes to the identifier of an aggregate, or record, it can literally be anything unique.

If you have a Customer then the system of record is probably your CRM system and any and all changes related to data that is maintained by the CRM system should only ever be changed there. If you need to have a Customer in your own, say, Orders BC then you'll have either only the CustomerId or a Customer value object that contains some minimal data that is, still, maintained in the CRM system. You wouldn't ever make changes to the data in your BC that is maintained in the CRM system; else they are immediately out of whack, and trying to replicate data back up-stream isn't only painful, but it is usually not a good idea (multiple conflicting updates from downstream systems, for instance). If you only have the customer id then you'd need to ask the CRM system, probably via and API of sorts, for any additional data. That is a design choice. Copies of data would need to kept up-to-date and messaging / event-driven architectures are useful here.

Now, if you'd like to relate any data to a particular customer in your own BC then you are creating a new aggregate in your BC that is related to the customer, but your BC is the system of record for that data. How you end up relating it is, again, a design choice. Let's go with a CustomerProfile in your Orders BC where you have some BC-specific data such as customer level (Gold, Silver, Bronze, etc.). You could have the Id of that profile simply be the same id from the CRM system, or you could map it. Perhaps there are different profiles based on some type and the profile has its own id but still also has a CustomerId that it is linked to.

This is something that isn't uncommon and is a form of a weak reference that one typically finds across systems. For instance, you receive an Invoice from a supplier and you register it in your system. You'll probably have your own invoice with all relevant data which includes an ExternalReference where you'd store the InvoiceNumber received from the supplier.

To answer you question as to whether there is anything wrong with having your own Customer in different BCs, there isn't necessarily anything wrong with it as long as it fits into the ubiquitous language of the domain experts. I've used the example of a seat in a stadium. The Finance BC maintains the asset register and keeps track of depreciation. The Maintenance BC cares about work orders and general maintenance of the seat. The Events BC cares about booking the seat for events. Each of these have their own view of the physical seat and they have different behaviours, and chances are that they are not event called Seat in any of the BCs. The Finance folks would call it an Asset, the Maintenance folks would perhaps call it Component, and the Events folks may call it a BookableItem (such as a seat, or a bicycle, or a VIP suite). However, when the maintenance department removes a seat for repairs it will need to publish an event notifying any interested parties. The Events BC would then mark that seat as Unavailable. All these BCs would need to know about the seat and have a common identifier, probably the one in the asset register.

I hope I understood your question/concern correctly.

Answer 2

I don't know that there is an authoritative answer to this, but I'll take a swing at it

I think what you have here is a communication pattern - that what you are proposing to do is "fine", but the language that you are using to describe it doesn't quite match the language as used by other DDD practitioners, and that the misalignment of language produces a conflict that isn't "real".

---

Using a Customer as an example, what's wrong with representing it as an entity in multiple BCs with different attributes in each BC (especially, when there's some BC related, user editable config, which would doesn't make sense in another BC at all), but sharing the same identity?

There's nothing "wrong" with doing this. The confusion comes from the fact that this may not be the right language to describe what you are doing.

Consider a single service with two data models that share the same key/correlationIdentifier, where the two models are independent in this sense: the two models can be locked independently, and there are no "domain invariants" that require modifying both data models within the same atomic transaction.

Naive example: we might have a data model for billing history, and a data model for order fulfillment, both accessible using the same key (/customer/12345).

Riddle: is it necessary that these two data models are accessed via the same AGGREGATE?

First we need an abstraction for encapsulating reference within the model. An AGGREGATE is a cluster of associated objects that we treat as a unit for the purpose of data changes.

We certainly could model this system as a single "customer aggregate", combining objects representing the billing data model and objects representing the fulfillment model combined in a single cluster and treated as a unit.

But if there's no advantage to doing that, then we could instead have a "billing aggregate" and a separate "fulfillment" aggregate; two distinct clusters of objects allowing us to access the underlying data models independently.

Our aggregate boundaries don't necessarily need to reflect the fact that these two data models are related to the same customer.

We get something similar when we start talking about data and multiple bounded contexts (BC). My service needs a non-authoritative copy of your data. Fine - but doesn't it even make sense to talk about your data as part of my aggregates? After all, "treat as a unit for the purpose of data changes" doesn't make a lot of sense if I don't have the authority to change it.

(Note that we may need to be a little bit careful here in thinking about why I need a stale, non-authoritative copy of your data - ex we want a report that joins my data with your stale data vs we want to copy your data into my data models, and compute the consequences of your changes in my domain.)