The DDD literature is quite clear that when a word/term has a different meaning for different users, a Bounded Context should be created to be able to separate the domain models.

I'm facing the situation where two different terms are being used to describe the same concept and I'm having a hard time figuring out how to handle this situation. Should I hold a popular vote among the domain experts to pick the most widely used term? Should we discuss it further and come up with a third name that would satisfy everyone (not sure it's possible)? Any other suggestions?

Note that in the UI it's possible to dynamically display the preferred term for the current user(group). I'm mainly talking about how to call the concept in the model and source code.

Some context:

Organisation has two existing off the shelf applications. Application A calls a concept Foo and application B calls the same concept Bar. Both applications have API's and I'm creating an integration application that allows users to get and manipulate data from both applications.

Application A is the source, when a new Foo is created, my application will create a new thing. Application B also reacts to the creation of Foo and my application will use data from B as well. Various users will work with the thing, until the process is complete and the thing will dissapear. My application will be used by users who work with Application A or Application B.

Update with more concrete context:

The domain is about a distribution center.

Application A turns customer orders into shipments, a single shipment can contain multiple orders from the same customer and large orders are split into multiple shipments. A shipment in this context is basically the container that will be shipped to the customer.

Application B takes those shipments, but calls them distribution orders. This application controls various processes to make sure the products end up in the correct container.

My application will integrate with both contexts and will contain anti-corruption layers, but that still leaves me with the main question of how to call the concept in my application. I'm leaning towards just picking a term (in collaboration with the experts) and describing it in the Published Language.

  • 1
    If there is consensus on the UI, then I don’t see who would oppose to using the same term under the hood. – Kris Van Bael Jan 14 at 21:25
  • Yeah, but there isn't. I will update my post. I meant to say that in the UI it's not so hard to dynamically alter the term on user preference. – Rik D Jan 14 at 21:30
  • Is there a term for this concept which is at least understood by all users, even if it is not the preferred term for a part of them? Do you really expect a huge confusion if the group which prefers term B will be presented with term A? – Doc Brown Jan 14 at 22:01
  • Is it really the same thing? Or are they two views on the same thing? Because if they are the same thing then either name is accurate possibly put it to them as a "Foo/Bar". If they are views on the same thing figure out what the name of the thing is and go with that. Details would help too. – Kain0_0 Jan 14 at 22:07
  • Both terms are understood by the experts, I’m not sure about regular users. Also future developers might be confused. @Kain0_0 Details about the actual domain might make the answers opinionated; I’m more interested in general patterns. – Rik D Jan 14 at 22:39

If domain experts use different terms consistently, there is a chance that there might be a subtle difference between two closely related concepts. Your narrative suggests that your two applications could be in two different bounded contexts. Each should have its DDD model that uses the term of the relevant domain experts.

Hypothetical example: one expert may refer to "items" in a shopping basket, whereas another expert may call them "products" in the inventory. At first sight they refer to the same concept, but in different contexts. But looking more closely will also reveal some subtle differences in the information managed: a catalogue item may have a commercial name and a sales price, whereas the product in stock may have a technical name, a storage location, a dangerous product category, and perhaps a cost (buying price, different from selling price).

Context mapping deals with relations between domains and related concepts across the boundaries of bounded contexts. Different strategies are possible. For example:

  • The domain experts may agree on using the same terms for overlapping concepts. The common terms make a shared kernel (this is frequently done in ERPs).
  • Every domain could loyally keep its own term that expresses its own reality, and some anti-corruption layer could be used to relate concepts in a way that allows independent evolution on both sides.

Be aware that the converse situation is trickier: when closely related concepts in different bounded context share the same name. This can be very confusing, because sometimes the domain experts themselves might be mislead to think they are speaking about the same concept and cannot agree on its definition.

  • Thanks for youw answer Christophe. I updated the question to provide some more specific details about the domain. My understanding of a Shared Kernel is that it's applicable when two contexts share a part of the same model. Since app A and B are off the shelf apps there isn't a shared model, certainly not in code. Is the concept of a Shared Kernel still valid then? – Rik D Jan 15 at 9:07
  • @RikD shared kernel implies a shared design. If these apps are off-the-shelf, they do not share design. I understand that the difference is about lifecycle and state: shipment is being prepared with a distribution order, when the distribution order is completed (the container is ready), which the shipment can be sent, and someday received (some after a passing through customs). It is indeed about published language. The question is then what point of view do you have on it: are you interested in preparing the container(delivery order)? or in following the container to the end(shipment) – Christophe Jan 15 at 12:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.