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.
Let's use an example to illustrate the problem. If I have 2 bounded contexts
CustomerService and an entity
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
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.