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.