Language is the basis of communication, even when designing large distributed data streaming applications. How do you align on a common language which not only supports services and API’s, but also supports an activity or intention? The need for a common vocabulary moreover, a naming convention that spans both intent (context) and things (Services, API’s, Topics etc.) becomes increasingly important, especially when your trying to find faults or available services through discovery.
In his book, Eric Evans (Domain Driven Design) describes the need to derive a Ubiquitous Language as a way of reducing the level of ambiguity that exists between users and development. Take for example the word “house-holding”; in the financial services domain house-holding has several interpreted meanings:
- For many, households represents a group of individuals that belong to the same family, generally related to one another. (People related to people)
- In financial services, households are groups of related accounts, which may or may not have the same mailing address. They may be a mix of individual accounts (or retail client accounts), business accounts, and accounts for entities such as trusts or estates. (Financial Accounts related to one another)
These 2 meanings are very different from one another, one is defining the relationship between people and the other the relationship between financial accounts. Given the following requirement, how would I derive the correct solution?
“As the head of a household, I can change the mailing address for any households that I belong to so that, any mailings will be delivered to that address”
As a developer am I solving for financial accounts or people? This ambiguity is what we are trying to solve for, how could this be represented in a way that would make the “intent” or context clear without spawning a series of meetings to discuss what the business is trying to achieve? What if the requirement included the context in a way that also described the system as well as the application(s) being impacted?
This is the ubiquitous nature we are trying to achieve, in language.
To that end I am proposing a simple naming convention that I call DDCL (Domain Driven Context Language). It assumes that some understanding in known related to your domain, as well as the systems and applications that comprise your ecosystem.
Domain: The outermost context (“Your Company)
Sub Domain: Business Domain (“Entity Types”)
Inner Domain: System Domain (“System Impacted”)
I-Squared Domain: Application Domain (“Application Impacted”)
Context: The context or intent to be derived (“Context of the request”)
Function: The function being performed (“like update, add”)
Using this naming convention, the requirement could be re-stated as:
Company.Role.System.Application.Context.Function
— or —
ABC.Investor.CRM.Salesforce.Mailings.UpdateMailingAddress
Whoa, I have a lot more information than I had before and think about what I can do with this statement. I can:
- Traverse the .(dot) notation to find all functions related to “mailings”
- Locate all “contexts” related to “Salesforce”
- Find all systems, contexts and functions that support “Investors”
As you can see, applying a pattern to the way we articulate a domain can not only reduce ambiguity, but also act as a discovery mechanism for all things supported by the system.
