When modernizing applications in the DoD, it’s valuable to take a step back and look at the big picture. This involves breaking down what specific terms mean and meandering through acronyms to understand what you’re working with. It means forming a dictionary of ubiquitous language to build better common understanding between developers, program managers/offices, and most importantly, users.
If users refer to combat missions as sorties, engineers should also refer to combat missions as sorties.
When using ubiquitous language in conversations, we form a common domain understanding that everyone can understand across the board – from users to designers to developers to program offices to COs.
How do we develop applications in a way that harnesses ubiquitous language and clear terms to create a common understanding between all these different parties?
Develop using Domain Driven Design (DDD).
Domain driven design is an approach to software development that makes software reflect real-world language by reconciling technical and non-technical terminologies that collide in software development.
At the core of DDD is the domain. A domain is a set of common requirements, terminology, and functionality. For example, in an online store we may have an inventory domain, a purchasing domain, a banking domain, and a users domain – all of which work together to form the online store as a whole, but are separate enough by business rules that can operate independently.
A great example in the use of domain driven design is Uber. Instead of making a monolithic application that tracks trips, payments, and user accounts all in one application, Uber split each aspect of the application into separate domains and services that are independently operated and updated.
One key advantage that can be achieved by developing and architecting your application into domains is that it naturally forms a common language surrounding a piece of functionality or business area. This eases communication between stakeholders and engineers which reduces risk of misunderstanding and provides flexibility within the application.
When domain driven design is implemented properly, everyone from the business team to developers and users use the same language and terms to describe the bounded context the application operates in.
Teams find communication much more effective when they’re able to link a domain model of the project and technical aspects in terms that everyone can understand. If everyone uses the same ubiquitous language and terminology, it becomes easier to keep track of the requirements for implementation. Terminology matters and using a set of ubiquitous terms can make or break a development team from understanding what is really needed to deliver value to users.
Because applications can be divided into distinct domains, this also allows for some flexibility within the application. Taking the example of Uber above, if a map needs to be updated in the Uber application, the payments service can still stay up while that is happening. DDD allows for software to be built in an easy to understand architecture that can be combined to form a fully integrated application.
DDD is transforming the way software is being developed, and this article only covers the tip of the iceberg. If you want to learn more about how DDD can help your organization, let’s pair and work towards forming a ubiquitous language today.
