Navigate Up
Sign In

How Domain Driven Design is playing a role in modernising software in Government

Publication Date: Jul 26, 2018
Written by Wayne Zammit, MITA Enterprise Architect within the Taxation Programme

Software, unlike wine, does not get better with age. As systems evolve they become stretched, pushing the limits of their technology until they eventually break.  Even if there is no need for the software itself to evolve, its operating environment (hardware, operating system, etc) eventually will, rendering the software obsolete or worse still inoperable. Resistance to keeping systems current is – as they say – futile and usually it is a gradual and ongoing process.

Every so often however, the need for a radical shift in the way software is written will become very apparent.  The drivers for modernisation can be both strategic and technical and businesses must be ready to truly modernise their systems when the opportunity presents itself.

The Programme Management Department (PMD) is the technical arm responsible for software development within MITA.  A substantial portion of Government IT systems being maintained by PMD know their roots in the mid-90s and although they serve their purpose well, they are limited to contribute business value in terms of agility in implementation, maintainability and interfacing with other systems. This presents an excellent opportunity for MITA and Government to modernise these systems and harness the benefits of current and emerging technologies to continue to drive the business forward.



One of the hallmarks of legacy systems is that over the years they get re-worked, enhanced, fixed and patched many times and potentially by many different people.  Most of the time tight schedules mean taking shortcuts and eventually these systems become difficult to maintain, improve, add functionality and carry an increase of support costs as well.  Sometimes this becomes such a challenge that the industry labels legacy systems “big balls of mud” or BBMs.  Tight coupling, bad design choices and general lack of separation of concerns all contribute to the formation of these BBMs.  

The current best practice of separation of concerns in design provides for the User Interface, business rules and data to be independent of each other.  Legacy systems implemented in the 90’s are typically two-tiered client server systems, which although serving the back office well will not allow the agile implementation of applications across the internet and over the mobile in an efficient manner. 

But it is not all bad news.  Having carte-blanche to re-design these systems from the ground up gives you the freedom to harness modern technologies and practices without restriction.  Furthermore, the BBMs can still be useful in terms of extracting business knowledge.  Software development in MITA is experiencing its most exciting times in recent years as Government has created the opportunity to completely modernize (and revolutionise) its IT systems.

Software Modernisation does not simply equate to upgrading systems to the most current version of a development tool, framework or language.  Modernising systems is primarily about radically re-engineering them to harness the benefits of modern architectures and platforms.   In many cases this means extracting the business knowledge out of these systems and re-develop them.  This is because legacy systems can be so far off the mark in terms of technology and architecture that a re-write becomes the only viable option.  When one considers the scale of IT systems in Government, one quickly realises what a mammoth task this modernisation process really is.  However, there are tools, techniques and methodologies that can help with this process and Domain Driven Design is one of them.

Domain Driven Design (DDD) is a software development approach specifically intended to tackle complex systems.  It aims at creating a collaborative environment for domain experts (people that know the business) and technical people.  This will enable them to embark on a domain discovery voyage, iteratively refining a model designed to tackle a business problem they are trying to solve.

This domain discovery process is the strategic foundation of DDD. During this process two very important concepts, the Ubiquitous Language and Bounded Contexts come into play.  The Ubiquitous Language is a collection of domain-specific terms, the language of the business.  This language is used in all forms of communication among the project team and crucially the same terms are used in the actual domain model source code.  This makes sure that the business concepts and the domain model being designed remain in sync and that the model, in effect, speaks the business.

Bounded contexts are the boundaries within which each domain model exists and operates.  Just as the meaning of words like “bear”, “fair” and “break” is dependent on the context in which they are used, so too are domain concepts dependent on the context in which they exist.  This is a crucial and powerful aspect of domain modelling as it allows models in different contexts to evolve independently of each other.  This is opposed to having one model being stretched and beaten into serving multiple and often conflicting domain contexts.  This has a significant effect on maintenance because it becomes much simpler to implement and test changes on a model that is focused solely on its own domain.  The model will only change if the rules in its own context change.  On the other hand, having a shared model means that a change originating from a given context has the potential to affect other contexts and is therefore harder to implement and especially test.
 
What about the architecture?  Many legacy systems are written as silos, with little or no interaction among them.  Commonly these are based on a 2-tier architecture with a “Fat Client” sitting on top of a database.  The term fat-client generally describes a desktop application that is bloated by mixing User Interface (UI) concerns with business logic concerns and data access concerns.  This is opposed to a more modern 3-tier approach where the UI, Business Logic (Domain) and Database concerns are entirely separate from each other.  

The first tier in a 3-tier architecture is known as the Presentation Layer which is basically made up of user interfaces such as desktop applications, web applications and mobile apps.  These applications are kept “thin”, only concerning themselves with User Interface and User Experience concerns and they contain no business or data access logic.  Applications in the presentation layer simply provide an interface for users to interact with the second tier, the Domain Layer.
 
The Domain Layer holds the all-important and valuable domain model, the business logic that is the very core of the solution.  Domain models are made up of code artefacts such as domain entities, value objects and domain services.  These artefacts are specialised bits of code responsible for enforcing the business rules (domain invariants) and are the product of tactical design decisions taken during the iterative discovery process.  Names of classes, properties and methods are all taken from the Ubiquitous language and the model is a natural software representation of the business processes, entirely independent of any presentation and data concerns.  Web API technology lends itself very well to the notion of a bounded context as it acts as a natural boundary around the domain model within.  Exposing the business logic through Web API allows us to interact with that logic from virtually any type of front-end application on the presentation layer.

The third tier is the Data Layer which in most cases is a relational database.  It is not uncommon in classic 2-tier systems to find chunks of business logic on the data layer in the form of stored procedures.  These functions are often born out of the necessity to extract pieces of business logic that are common across the “fat clients”.  Clearly however, in a 3-tier architecture this logic belongs in the Domain Layer and just as the Presentation Layer is reduced to presentation (UI/UX) concerns, so too is the Data Layer reduced to data storage concerns.  Limiting the data layer to simply storing data, drastically reduces the exit cost of that database technology.  It is also much simpler to abstract away the database from the domain logic.

It is important to realise that the needs of a domain model are at logger-heads with the needs of the data model (database schema).  The structure of the database tables is dictated by factors like avoiding data duplication (normalisation), speed of data retrieval, indexes etc.  These are all technical constraints which the domain model should not be concerned with, or worse still, limited by.  So, abstracting away these database concerns from the domain layer gives us the freedom of designing a domain model that best suits the business without any restrictions that might be imposed by the data model.  Crucially, this means that the most valuable bits of code in our system – the domain model – is completely independent of both presentation and data concerns.  In turn this means that the Business (Client) is free to change the application and/or database technologies with relative ease without affecting the all-important and delicate domain model. 

This is just the proverbial tip of the iceberg in terms of modernisation.  Modernisation encapsulates a myriad of other significant aspects that need to be brought together in harmony including development approaches such as DDD, mindset, upskilling and technology itself.  MITA is currently working on this coming-together of modernisation components.  One tangible deliverable is the current process of adopting an on-premise hybrid cloud that will open further opportunities and tools to help keep up with emerging technologies and ensure that our systems reap the inherent benefits.