In software development, the trend for years has been to move away from monolithic software architectures to modular components. Especially in the financial sector, historically evolved, complex core banking systems are the rule rather than the exception. In the wake of digital transformation, however, the demand for more agility and scalability in IT is also increasing in the banking industry. In order to meet these demands, modernization requires a methodology that concentrates on business functionality and can handle complexity at the same time: Domain-Driven Design.
A large amount of data, customized operations and complex processes make every software project in the financial industry challenging. The project realization presents both the software developers and the domain experts with a difficult task, since many aspects need to be taken into account and implemented comprehensibly. More importantly, both sides must speak the same language already at the planning stage in order to implement the specific functional requirements in a technically sound way. The use of a methodology such as Domain-Driven Design (DDD) makes it possible to precisely delineate these requirements, to define them unambiguously for all concerned, and thus also to implement comprehensive software solutions for banks in a clearly structured manner. This also corresponds to the general tendency in the IT sector to move away from monolithic systems towards a structure composed of microservices.
What is Domain-Driven Design?
At the beginning of most projects, there are many question marks. Requirements must be clarified, and business processes must be understood correctly, before software programming can even be started. This is where DDD enters the game: detached from technical details, DDD supports developers and domain experts first of all in planning how business functionality and domain logic can be mapped within the software architecture.
Eric Evans, an expert and business consultant in software design, coined the term Domain-Driven Design as far back as the early 2000s in his book Domain-Driven Design: Tackling Complexity in the Heart of Software. He describes the method as a strategic approach that uses language-centric and domain-centric principles and patterns to model complex software systems.
From a Convoluted Domain to a Structured Domain Model
A domain is the knowledge area for which a software solution is to be created. It describes the business functionality with all its processes, elements and their relationships and interdependencies. DDD is based on the principle that all project participants concentrate on the domain at the beginning of the life cycle of the software. The knowledge of the domain experts should be communicated and structured in such a way that architects and developers gain a comprehensive, common understanding of all functional challenges.
The result is a Domain Model that maps all functional relationships and depicts domain knowledge in an abstract, structured form. Evans describes it as a "set of concepts built up in the heads of the people on the project, with terms and relationships that reflect domain insight."
The Domain Model is not detached from the software but should evolve with it. Code and model are mutually dependent in the DDD concept and should both represent the identical, most current state. If elements defined in the model cannot be implemented in the code, the Domain Model is readapted. Only if the DDD approach is pursued consistently, is its added value for the project ensured and an effective development process secured, in which both domain experts and developers can keep track.
Communication is the Key to Consistent Projects
The elements and relationships defined in the Domain Model must be communicated in a way that is understandable to domain experts and developers alike. The result is the so-called Ubiquitous Language, a universal language "tailored to the domain, while being precise enough for technical development," says Evans. This domain-based language serves as the basis for all communication among the team. It is the common thread running through the project and is used by all participants to clarify central concepts and their interrelations. These domain terms should always be used with the same understanding, whether in the documentation, the tests, the specification of requirements or in the code itself.
DDD counteracts what Evans identifies as one of the biggest challenges in projects with many interdisciplinary points of contact – an inconsistent linguistic base. Misunderstandings and misinterpretations between the domain and IT experts are prevented by using the Ubiquitous Language to model the functional solutions.
No Meaning Without Context
With the Ubiquitous Language as a tool, the Domain Model is broken down. All business contexts are defined and their boundaries carefully delineated; this is called Bounded Contexts. Since linguistic unambiguousness is given only within a limited Bounded Context, domain terms and business-relevant processes must refer to exactly one context. This way duplicates within the system are avoided.
The concept of 'customer' is a widespread example of this principle. Is someone only a customer when he or she buys something, or is it enough when he or she visits a website? Are terms such as 'user', 'end user' or 'visitor' used interchangeably? The respective context is decisive for the conceptual meaning and the resulting relationships and interactions.
A Context Map provides an overview of several Bounded Contexts and maps their technical and organizational relationships and dependencies. The definition of terms associated with the respective context leads to a software system that remains stable even if determining factors of the project change, such as the technical infrastructure or the teams involved.
From the Domain Model to Complex Software
How does uninspiring theory become lively software? Christian Sternkopf is responsible for product management at knowis. As a product manager, he talks about his experience with DDD and describes how it is used in the knowis software solutions.
Domain Driven Design might be considered a proven concept given the fast pace of digital technologies. Why is this design approach currently getting so much attention?
The explanation for this is the current trend to build microservices architectures. Software architects are rediscovering the potential of DDD in modeling these because the Bounded Contexts are a kind of template for the scope of microservices. These are autonomous components that break monolithic applications into small and agile architectural units.
How is DDD used at knowis?
This is exciting because DDD is used by knowis in two ways. On the one hand, we use it in the development process of complex products – which of course requires a lot of discipline, but it's worth it. As a banking software provider, we benefit from the bridge DDD builds between the domain side and the technology side. Here it facilitates collaboration in product development through the use of a common language.
On the other hand, our product supports the basic principles of DDD and thus makes it possible to transfer theoretical concepts directly into a domain model. With our application, business analysts and solution engineers work together to create a common model, from which stable software emerges.
Is there an optimal approach to DDD?
To model a domain, it is essential to know the functional requirements that the software solution should ultimately meet. It may therefore be a good starting point to determine User Stories, that is user needs, by means of User Story Mapping.
When it comes to creating microservices using DDD, so-called Domain Events are a key element. They are used to detach domains across different microservices. In order to identify events and their dependencies, Event Storming, for example, can be useful – an interactive workshop designed to simplify the planning of complex software and an ideal starting point to use DDD in the for this process.
Conclusion
Complex software systems can hardly be mastered without domain modeling. A stable IT architecture is based on a modularized, logically structured expertise that develops from the DDD core concepts of Domain Model, Ubiquitous Language and Bounded Context. The consistent utilization of DDD in projects with a high level of complexity leads to more stable, more efficient software, which can be more easily extended and adapted to changing business processes due to the strict separation of the functional contexts. The foundation of this software architecture enables the creation of scalable and flexible solutions, which banks need today and in the future.
Image Sources: Teaser: fanjianhua - 636173198 - iStock; Infographic: knowis AG
