CODEWITHSUNDEEP
design-patternsdomain-driven-designcqrsevent-driven-designbounded-contexts
Kyle
Kyle

Reputation: 186

Identity Reference between two bounded contexts

I am looking to get the best practice around DDD/CQRS principles for handing relationships between bounded contexts.

We have two BCs Property Management Context and Tenant Portal Context. We have the Home aggregate in the Tenant Portal context, which operates completely independent of the Property aggregate in the property management context. However, on creating a Home we are finding the need to store the PropertyId from the other BC in the initial event as a look-up.

I was initially of the opinion that event identity references across BCs were discouraged. However, someone in my team challenged that opinion and I'm struggling to find the resources that support either argument.

Is it considered acceptable to reference aggregate roots in other bounded contexts?

If it isn't recommended, would a better alternative be to purposefully obscure the relationship by trying to use context-specific language, such as LookUpCode or ExternalReferenceCode. Even though, there is a hidden implicit understanding that this is actually the PropertyId and unlikely be anything else for the near future.

Two different contrary suggestions I have seen to a similar question are:

Upvotes: 3

Views: 1438

Answers (1)

Matt Timmermans
Matt Timmermans

Reputation: 59144

The suggestions you quote are not actually contradictory.

It's reasonable to use foreign IDs to reference entities defined in other contexts, but:

  • If a BC uses a foreign ID, then it should not also use that as the ID for an entity of its own; In fact
  • It usually not a good idea to assume a 1-1 correspondence between internal entities and foreign entities; and
  • It's not even a good idea to assume that the foreign ID is an entity ID at all. It is an ID that is required to interact with the foreign context. It is defined in terms of what you can do with it in those interactions, and should have no other purpose.

So, for instance if TenantPortal needs to perform certain actions or get certain information from PropertyMgmt, then TenantPortal.Home can contain a PropertyRef that it can use to do those things or get that information. It has no other purpose, and should not be (part of) an ID for anything in TenantPortal.

The fact that a PropertyRef is an entity ID in PropertyMgmt is irrelevant to TenantPortal.

Upvotes: 3

Related Questions