I got this question from a fellow named Martin today:
Real simple … most of the discussion on DDD surrounds the design in terms of the ubiquitous language.
What if you are developing a product that is designed to be a tool for
a certain industry, say marketing, but the processes and terminology
all differ according to the marketing company that is in discussion.
To be specific, one company may use the term Client and the other Customer?
How do you accommodate the difference in terms? Do you code to a common denominator or do you just pick one and go?
Great question; in product development we’re often trying to make a general solution that solves the common problems of customers that have different languages. There’s no way around that.
First, find those elements that are universal. Question if there’s really a need for all of this customization or if your clients are OK with calling a client a customer. Having a ubiquitous language that can be used end-to-end, from developer to end user, is extremely valuable and kind of the original point.
For variable terms you should, in my estimation and experience, form an internal ubiquitous language that’s adhered to across product management and software development. In cases like this, you’ll can potentially also apply DDD guidance to a generic subdomain that handles terminology. This domain usually goes by the name “localization,” only slightly extended to allow clients to change terminology. This is exactly how we handle the differences in terminology (silly) between agile methods like Scrum and XP in our product at VersionOne. We simply have a set of components that handle the change between backlog item and story, iteration and sprint, etc.