3

If my domain has several Bounded Contexts, but only ONE team will work on all contexts, should I develop an Ubiquitous language for each context? or should I have only one and force to into all contexts?

The bounded context definition from Evan's book states:

A BOUNDED CONTEXT delimits the applicability of a particular model so that team members have a clear and shared understanding of what has to be consistent and how it relates to other CONTEXTS. Within that CONTEXT, work to keep the model logically unified, but do not worry about applicability outside those bounds. In other CONTEXTS, other models apply, with differences in terminology, in concepts and rules, and in dialects of the UBIQUITOUS LANGUAGE.

I don't understand what is meant by "dialects of the UBIQUITOUS LANGUAGE". Should I develop a universal ubiquitous languge then modify it for each bounded context?

My main problem is if a single team is going to work on all context they might get confused by the constant change in the terminology.

UPDATE:
Let's use an example to illustrate the problem. If I have 2 bounded contexts Operations and CustomerService and an entity Order.
A customer may request a refund. In the Operations context this is called a refund while in the CustomerService context it is called a cancellation. In my models I gonna have something like order.refund() or order.cancel().

The question is should I have 2 models for the order entity one with a method called refund() while in the other context a method called cancel()? or should I force a single terminology?

The implementation of the refund process might the same or different.

| improve this question | |
  • Good question. I've been in that position before. In our case we had 1 application to help manage 3 departments that had roughly the same business processes but in three entirely different domains. Their languages were similar enough to make us think UL would be easy, and it was easy at first. However it eventually became quite cumbersome as we ended up having to prefix our Entities with their Department's name. Also, meetings with 2 or more of the departments quickly became confusing for the department users (not necessarily for the dev team, though). It's a tough one! – MetaFight Dec 16 '13 at 10:59
2

The purpose of the ubiquitous language is to use terminology that both your customer and the programmer can understand. The terms that describe business entities must be terms that apply to that particular business. Consequently, it follows that the ubiquitous language is going to change somewhat with the specific problem domain being worked on.

| improve this answer | |
1

If my domain has several Bounded Contexts, but only ONE team will work on all contexts, should I develop an Ubiquitous language for each context? or should I have only one and force to into all contexts?

Changing the spelling of this question slightly; if your domain has several Bounded Contexts, but only ONE team will implement all of them...

...then that team needs to be multi-lingual; speaking in the ubiquitous language specific to the BC that they are working in at the moment.

Trying to come up with model that addresses all of the concerns is the anti-pattern that the concept of a bounded context aims to correct.

| improve this answer | |
  • "then that team needs to be multi-lingual" Perfect description – Wahid Bitar Sep 2 '16 at 6:57
-1

If I understood correctly, you should be cautious with the ambiguities. You need to create a Context Map, see the "Example 1: Same term, different meaning".

| improve this answer | |

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.