I was asked why the concept named Tenant is used in all three Bounded Contexts for the example code for my book, Implementing Domain-Driven Design. Is it because a Tenant is the exact same thing in all three Contexts? Actually this is a good example of when concepts in two or more Bounded Contexts have the same name but have different meanings and uses. Let’s consider how they differ.
In the Identity and Access Context a Tenant is an Aggregate that has a life cycle. It can be disabled and can be used to invite new registrations, and even carry out new registrations. If that Tenant is disabled, no users registered under it will be able to authenticate. (See the discussion in Chapter 5.) Here a Tenant also has a globally (SaaS wide) unique identity.
In the Collaboration Context there is a concept named Tenant, while in the Agile Project Management Context there is a TenantId. In both cases—Tenant and TenantId—these are modeled as Value Objects and used only for identity. One important reason for these identities is to ensure that the only users within a specific tenancy (an organization that rents/hires use of the SaaS services and stores its related data) can use objects within that tenant.
Why do you think the two teams that respectively work on the Collaboration Context and the Agile Project Management Context didn’t use different names? After all, the teams need not be tied to the original name, Tenant, just because they hold the identity of the Tenant originating in the Identity and Access Context.
True, the teams could have chosen to use the name Subscriber or Company in the two consuming Contexts. They certainly could have done so since the Ubiquitous Language of each team is formed by the team. But what would be the merit in that when Tenant is clearly understood throughout the entire SaaS organization (SaaSOvation)? If new team members are added over the life of each project, it’s just one more detail to have to explain why the Tenant over there is represented as a Subscriber over here, and why our team thinks it is important to distinguish the concept as a Subscriber in our own Context.
In practice, using Subscriber or Company or some other name seems to have little or no justification. In Collaboration, for example, the team doesn’t care anything at all about subscriptions. Further, Company isn’t fitting either, because perhaps the Collaboration subscriber is a school and not a commercial organization. In the end, Tenant works just fine everywhere, and actually in this case everyone who works at SaaSOvation will know exactly what it means.
Still, this specific example in no way indicates that concepts in any given consuming Bounded Context that “shadow” a concept in another Bounded Context must reuse the name of the originating concept. The concept name, the identity, and the limited number of attributes consumed by the foreign Context must be carefully chosen by the team that is responsible for how the local concept is modeled.
