In the first part of this article we get to know Domain Driven Design (DDD) and some of its benefits in the process of developing information systems. In that section we also get to know some basic terminology to better understand DDD more deeply. To note, Domain Driven Design was coined by author Eric Evans (2003) with the title “Domain Driven Design: Tackling Complexity in The Heart of Software”.
This second part of the article will discuss the need for DDD implementation in an information system development, namely the need for Domain Experts and Ubiquitous Language.
First challenge : Domain Expert
Domain experts are people with special skills in a particular field. For example, financial accountants are domain experts in the field of financial accounting, general practitioners are domain experts in the field of human health, and so on.
Domain experts work in an environment with a clearly defined work context, in DDD terms this is called a bounded context. They master business understanding, are able to analyze resource requirements for each job, are adaptive to internal and external business changes and are able to make decisions for their own units. They can distinguish which work is their responsibility and which they must leave to other experts.
The most common challenge when implementing Domain-Driven Design is finding subject matter experts to collaborate with on a project that is outside of their typical realm. Developers and domain experts need to have enough overlapping knowledge in order to bring a successful product to life. The knowledge in question is an understanding of how a business process runs and the business rules that apply in a domain.
Another challenge is dealing with other domain experts (external domains), you need to harmonize the way of thinking and understanding of how it works between domain experts. The problem that is often encountered is that domain experts have different “terms” to describe an entity. So it takes a domain expert who is able to communicate well with other experts.
This challenge is quite natural because domain experts are more focused on completing or improving the outcomes of their respective work domains. Therefore we need a language or an understanding of the entity understanding of each domain expert and developer, which is referred to ubiquitous language.
Ubiquitous Language is a must
Ubiquitous Language is a common language in one team, created by programmers, businesses, product owners, and testers. Ubiquitous Language is a term coined by Eric Evans to establish a common and rigid language between the developer team and the user.
This language is based on the domain model used in application development, so it must be rigid and rigorous because software development cannot handle ambiguity well. This language can develop as a team increases understanding of the problem domain to be solved by the software. This is where the main role of domain experts and software developers is needed.
The next article will not discuss the technical side of DDD. We will talk about microservices, a new paradigm in system design. With microservices, the need to create self-sustaining and scalable subsystems can be realized precisely and efficiently.
