How to name a domain concept when experts use different terms?

Question

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.

Answer 1

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.