3

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:

Kyle
  • 186
  • 5

1 Answers1

3

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.

Matt Timmermans
  • 53,709
  • 3
  • 46
  • 87
  • So what you're saying Matt, is that TenantPortal.* can not known entity IDs from other BCs, but it can know some *information* that it can use to trigger behaviour in another BC (via events/svcs?)? So there is no way in TenantPortal.Home to know that it belongs to a certain PropertyMgmt.Property, because those are diff contexts? What can you do then? Store PropertyId in Home only for the scope of calling a domain service or emitting domain events? I mean is that all you should be allowed to do? So even if PropertyId is an entity ID you are not allowed to think of it that way in Home? – Paul-Sebastian Manole Apr 09 '21 at 10:08
  • No, nothing so restrictive. It's just that the designation of something as a property *ID* implies not only that it refers to a property, but that it is the canonical way to refer to a property within PropertyMgmt, that it always refers to the same property, that it is the *only* ID that refers to that property. The PropertyMgmt domain just shouldn't be making those kinds of guarantees to other BCs if it can be avoided. – Matt Timmermans Apr 10 '21 at 20:49
  • All this property vs Property talk is confusing. For example, I think you meant "the designation of something as a Property ID implies..." and not property with a small p, which might imply that you're talking about an ID property (like object.ID). And btw, thanks for clearing things up, I got it now. :D – Paul-Sebastian Manole Apr 12 '21 at 09:56