Insight / 14.09.18
Regardless of the sector, enterprise software has already transformed the operational processes in most businesses. However, technology has evolved to the point where many enterprises have become digital enterprises, where their core value proposition and competitive advantage derives from investment in technology. With the increasing pressure to utilise digital to gain a competitive advantage, the need for businesses to build their own software becomes essential.
Off-the-shelf software provides no competitive advantage, so although this may be the most cost-effective solution for supporting business functions, for the core business objectives, it just isn't sufficient. This necessitates software and application development as one of the critical capabilities of enterprises wanting to thrive in this digital world.
So if modern software development must be at the core of the enterprise, how do you maximise the business value of software written and mitigate the risks? A traditional approach like waterfall - where all the design is done up front before development begins - leads to complex software that doesn't fit the requirements and delivery of value to the business only after a long period of significant investment. An agile approach allows value to be delivered much faster. And the short feedback loops allow for course correction, so the software is better aligned with the business goals. But while an agile approach makes the most sense to gain a competitive advantage for enterprise building software, for complex business processes, this is not enough to ensure that the software delivered truly aligns with the process and provides that all-important competitive edge. That's where domain driven design comes in.
DDD is a methodology for building enterprise software for complex business needs with a strong focus on delivering the highest value possible.
One of the biggest problems in building complex enterprise software is the disconnect between the people who understand the business model - the domain experts - and the developers. You don't have to go far to hear stories about friction between developers and business experts. Often, developers will create their own language to understand the business that doesn't align with the language of the domain experts. This results in software models that don't accurately model the business process and creates an overhead of translation.
So you can better understand how domain driven design can help your enterprise we are going to cover a few of the core ideas in the methodology.
Let's start by defining what we mean in DDD when we say domain. A domain is a sphere of knowledge, influence or activity. If we take the example of a pharmaceutical company, their overall domain is the discovery, manufacture and distribution of medicines. However, within an enterprise, there will be several sub-domains (often referred to just as domains in DDD, since we seldom reference the overall domain). So for a somewhat oversimplified view of a pharmaceutical company, we might split it into the following sub-domains:
Here we have identified drug discovery as the core domain - discovering a new drug and getting it approved and patented is critical to the success of the company. A core domain is where the biggest investment of effort should be. Supporting sub-domains are usually something fairly generic that a lot of businesses will have to do like accounting - a pharmaceutical company would not build their own accounting software before creating software to solve problems in drug discovery.
This may seem like relatively rudimentary business analysis, but identifying the core domain(s) is paramount to ensure that investment is not wasted on generic problems that could be solved by existing software or services. We must focus on the problems for which solutions will provide the highest possible value for the enterprise.
In order for any non-trivial software project to succeed everyone must be speaking the same language and communication between stakeholders and developers needs to flow freely. This is where the concept of a Ubiquitous Language comes in.
The way we discover and understand the business needs is through the use of language, so if we wish to create rich software with the biggest returns then having everyone speak the same language is crucial. When using DDD the business experts and developers collaborate to create and continuously refine a glossary of the relevant business terms for the process being modelled. This is useful for several reasons; firstly it means that the developers speak the language of the experts, which reduces the overhead of translation. Secondly, it means that the correct terminology is distilled into the actual code so that the developers begin to think about the problems in the language of the domain. Close collaboration between the people who really understand the business and the developers is essential to create valuable software that can evolve with the needs of the business.
Every business has more than one sub-domain, for example, every business has a requirement for accounting and the accountants will use different language from business experts in another domain or department. We cannot force the entire enterprise to use the same terms, even if they refer to the same thing. And creating software that doesn't reflect the structure of the organisation is a recipe for failure. This is where bounded contexts come in.
To keep everyone on the same page, we need to draw a linguistic boundary around the different domains of the enterprise; we call this linguistic boundary a Bounded Context. A Ubiquitous Language is applicable only within a Bounded Context, that is to say, there will be one glossary for each sub-domain of the business. The software is then designed to reflect this separation of concerns which allows developers to keep their focus narrow and not create a spaghetti of dependencies.
Discover some of our other insights
Start progressing your business
Contact our team of experts today;Contact