Elaboration of a Domain Model for Migrating the Monolithic Software

Architecture of a Data Management Server into a Microservice

Architecture

Christian Zaschke

Fraunhofer IOSB, Karlsruhe, Germany

Keywords:

CSD, Coalition Shared Data, DDD, Domain-Driven Design, Domain Model, Microservice.

Abstract:

This paper presents the necessary steps for creating a useful domain model for the Coalition Shared Data

(CSD) domain. After describing the basic procedure of creating a domain model following the principles of

domain-driven design (DDD) some concrete results achieved and experiences gained throughout this process

are depicted. The domain model is the backbone for further development activities to migrate the monolithic

software architecture of an existing data management server into a loosely coupled one according to the princi-

ples of microservice architectures. Major challenges with the creation of such a domain model and the beneﬁts

of loosely coupled software components in the CSD environment are outlined.

1 INTRODUCTION

Collection, analysis and processing of huge amounts

of data nowadays are crucial abilities to meet the de-

mands of a digital and globalized world. These ca-

pabilities help to gather necessary information about

people and organizations, their speciﬁc actions and

intentions, with the aim to get superior knowledge.

As a basis for making data available to the right peo-

ple at the right time with the right granularity (Za-

schke et al., 2016) a process for storing, disseminating

and maintaining data has to be deﬁned, implemented

and established. To involve a critical mass of stake-

holders in this process, participation has to be made

possible in a beneﬁcial, cost-efﬁcient and sustainable

way. One way to achieve this is to establish common

standards.

One of these interoperability standards is the

NATO Standardization Agreement (STANAG) 4559

((NSO), 2018) which deﬁnes the interface of a dis-

tributed data storage for enabling data sharing be-

tween different NATO nations and their partners.

The STANAG 4559 speciﬁes standardized inter-

faces to allow ingesting and retrieving relevant Joint

Intelligence, Surveillance and Reconnaissance (JISR)

products into a so called Coalition Shared Data (CSD)

Server. Whether data is relevant (for oneself or for

other partners) or not has to be determined by the

https://orcid.org/0000-0002-6351-491X

people who collect and process them. The desig-

nated JISR products follow standardized data formats

as well to make sure that CSD client systems request-

ing those products know how to interpret and process

them. CSD client systems using the STANAG 4559

interfaces are able to ingest new products and to place

speciﬁc requests on the server to get the appropriate

products in return.

As the STANAG 4559 doesn’t specify architec-

tural aspects of an implementation of the interface,

a typical STANAG 4559 implementation is built up

monolithically and, thus, closely coupled.

The paper addresses the necessary steps, chal-

lenges and beneﬁts of a migration from a monolithic

software structure to a loosely coupled microser-

vice architecture following the principles of domain-

driven design (DDD) as a precondition for a behavior-

driven development (BDD) approach in a later phase.

2 FROM DOMAIN KNOWLEDGE

TO A DOMAIN MODEL

According to the principles of DDD, a domain model

for a speciﬁc area of application has to be developed

to solve a problem in the real world. According to

(Evans, 2015) a domain is deﬁned as ”a sphere of

knowledge, inﬂuence, or activity. The subject area

to which the user applies a program is the domain of

212

Zaschke, C.

Elaboration of a Domain Model for Migrating the Monolithic Software Architecture of a Data Management Server into a Microservice Architecture.

DOI: 10.5220/0008319402120218

In Proceedings of the 11th International Joint Conference on Knowledge Discovery, Knowledge Engineering and Knowledge Management (IC3K 2019), pages 212-218

ISBN: 978-989-758-382-7

the software.”

The domain model is the basis for a software spec-

iﬁcation which could be created following a BDD ap-

proach.

The features deﬁned in the software speciﬁcation

represent the real world requirements. By implement-

ing those features the corresponding problem of the

real world is being addressed and solved appropri-

ately.

2.1 Ubiquitous Language

For the development of a domain model both domain

experts and technical experts have to be involved.

The domain experts have a comprehensive knowledge

and their own business-speciﬁc language describing

business-speciﬁc terms and concepts. Technical ex-

perts, on the other side, typically use a very technical

and highly speciﬁc language. They have great experi-

ence in the development of complex systems and are

adept at using state-of-the-art methods and technolo-

gies.

As a ﬁrst step towards a domain model, it is cru-

cial to deﬁne a common and compulsory vocabulary

- a ubiquitous language. To achieve that, all involved

stakeholders enter into intense interactions with each

other. In a continuous, iterative and collaborative pro-

cess technical and domain experts determine a collec-

tion of common terms and specify a set of features.

This creative process is called knowledge crunching.

In knowledge crunching events all stakeholders

are brainstorming all their terms, concepts and issues

of the speciﬁc domain. The domain experts have to

abstract their knowledge, whereas the technical ex-

perts have to understand and formalize the domain

knowledge. Experiences of the stakeholders in simi-

lar domains or with earlier projects could be advanta-

geous and complement the domain knowledge. Sub-

sequently, the huge amount of input is being harmo-

nized, distilled, restructured and streamlined.

The result of this process is a collection of terms

and a feature list. All terms need to be clearly deﬁned.

The relevant features have to be described accurately.

As a result, the ubiquitous language for the domain is

deﬁned and ready to be used by all stakeholders in the

following development and operating phases.

When talking about a domain-speciﬁc term or

concept every involved stakeholder uses the same

word for it. Likewise, each involved stakeholder

should have a clear comprehension about every de-

ﬁned term. As a consequence, in conversations and

written texts every stakeholder has the same under-

standing of a speciﬁc term or concept. This helps

avoiding ambiguities and misinterpretations and leads

to a clear and efﬁcient communication and documen-

tation.

In case the team realizes that the deﬁnition or

name of a term or a concept is not useful or not correct

anymore, it needs to be revised and again collectively

deﬁned and agreed upon. This procedure helps keep-

ing the ubiquitous language clean and up-to-date and

gives the ﬂexibility to react on changes throughout

the whole development. The implications of a change

in the ubiquitous language and thereby in the domain

model will be examined in the next section.

2.2 Domain Model

The domain model is the pivotal point of a software

project following the principles of DDD. It describes

the interrelationship of central terms and concepts of

the determined common language and can therefore

be seen as the abstraction of the underlying domain.

According to (Evans, 2003) these terms and interrela-

tionships provide the semantics of a language that is

tailored to the domain while being precise enough for

technical development. The software speciﬁcation,

forming the basis of the implementation, is build up

on the deﬁned domain model which leads to a strong

binding between the domain model and the derived

implementation - the ”crucial cord that weaves the

model into development activity and binds it with the

code” (Evans, 2003).

The elaboration of the domain model is an iter-

ative process in which the experiences and insights

gleaned throughout the project are reﬂected. Thus,

the domain model may be subject of change all the

time. These changes are typically based on contri-

butions from domain experts and developers. If the

software project needs, at a given moment, some kind

of conceptual or linguistic change, e.g., additional

terms, new wording of existing terms or new relations

between concepts, this change is applied at domain

model level ﬁrst. This change has implications to the

software speciﬁcation (e.g., the class diagram) and in

turn to the code which again emphasizes the strong

binding between model and implementation.

2.2.1 Conceptual Modeling

DDD is not a technology or a methodology - it is a

way of thinking and a set of priorities for accelerating

software projects that have to deal with complicated

domains (Landre et al., 2007).

Effective modeling as deﬁned in (Evans, 2003) is

obtained by performing the following ﬁve activities.

• Binding the model and the implementation;

• Cultivating a language based on the model;

Elaboration of a Domain Model for Migrating the Monolithic Software Architecture of a Data Management Server into a Microservice

Architecture

213

• Developing a knowledge-rich model;

• Distilling the model;

• Brainstorming and experimenting.

As the implementation is strictly based on the domain

model they are ”bound” with each other. The domain

model is used by the developers throughout the whole

development process. New insights and experiences

gained during the development could lead to changes

in the domain model. Whereas a change in the model

implies changes in the implementation.

The model contains terms which are part of the

ubiquitous language described in section 2.1. This

language is common to all participants involved in the

software project including domain experts and devel-

opers. Through the cultivation of a common language

base concepts become linguistically describable. In

this way, concepts could be communicated unambigu-

ously and translations between different notions and

concepts depending on the expert domains could be

prevented. The domain model is thereby used as the

backbone of the ubiquitous language.

The domain model is more than just a representa-

tion of data structures, it must contain the whole do-

main knowledge. It contains data structures and ob-

jects but also ideas, behaviors and enforced rules. To

a certain extent this so called knowledge-rich model

also contains system behavior and various knowledge

relevant for the domain and the system.

As the domain model contains all, but also only,

the relevant knowledge, relevant knowledge has to be

added continuously and knowledge that is not relevant

any more has to be removed from the model. Through

this process of adding and removing knowledge from

the model the desired domain model distills from the

total amount of domain knowledge.

The domain model is subject to changes through-

out the development process and could be improved

through brainstorming sessions and experimentation

meetings between domain experts and developers.

The output of the massive experimentations and dis-

cussions taking place is the distilled and knowledge-

rich model - the domain model.

2.2.2 Technical Modeling

In this section the development of the domain model

is being described from a more technical perspective.

The desired output of the domain model develop-

ment process is a formalized mapping of the technical

links inside a domain.

A domain typically consists of several separable

sub-domains in which it could be broken down. In a

domain model sub-domains are represented through

packages.

A self-contained sub-domain is called bounded

context. Bounded contexts serve as candidates for

the derivation of microservices in a later step (Mil-

lett, 2015). In the beginning, a concrete partitioning

in bounded contexts is not known. The partitioning

has to be developed in various iterations using an ex-

ploration and experimentation approach.

A context map deﬁnes the relations between bounded

contexts by the use of shared entities, i.e. shared

models and shared objects. The context map is an

overview page and should be part of every domain

model. It provides a brief overview over all rela-

tions between all bounded contexts. From a developer

team’s perspective a context map reﬂects the kind

of relationship their bounded context has to another

bounded context and indicates areas where inter-team

communication is imperative (Vernon, 2013).

Domain views subdivide the model. They depict

static and dynamic aspects of the domain and visu-

alize relations between domain objects. Static as-

pects are depicted by relation views. Whereas process

views depict the dynamic aspects of the domain.

Examples for a context map, a relation view and a

process view were given in section 3.2.

3 ELABORATION OF THE CSD

SERVER DOMAIN MODEL

In this section the creation process of the CSD Server

domain model and the lived experiences will be ex-

plained.

3.1 Ubiquitous Language for the CSD

Server Domain

The development of a domain model for the CSD do-

main started - similar to the approach described in

section 2.1 - with several meetings of CSD experts

and experienced technical personal. In the ﬁrst meet-

ing the general concept was presented and explained.

Because of the abstract level of detail only a few ques-

tions were asked and answered.

The second meeting started with some questions

from the developers about aspects that were not men-

tioned yet or not completely understood. After that,

the developers presented their typical approach of de-

veloping a domain model for a new domain. At this

point, both sides - the domain experts and the techni-

cal experts - had a rough idea about the other experts

knowledge and procedures.

The next two meetings served as the communica-

tion platform for developing the ubiquitous language

KMIS 2019 - 11th International Conference on Knowledge Management and Information Systems

214

explained in section 2.1. Every term mentioned in

these meetings which was related to the domain was

written down by the developers and explained by the

domain experts.

During this process, even the domain experts

learned something about their own domain by clearly

deﬁning and differentiating the considered terms.

Fine-grained differences between the interpretations

of some terms among the domain experts were re-

vealed and discussed. The various questions of the

developers trying to ﬁgure out the meaning of any

term and his relation to other terms helped them to

get used to the domain step-by-step. It also helped

the domain experts to extract and transfer their do-

main knowledge to the developers.

The knowledge got formalized by establishing

a common vocabulary in which all domain-speciﬁc

terms were listed and clearly deﬁned. This list of

terms and their deﬁnitions was produced by the de-

velopers which also presented them to the domain ex-

perts. After the presentation all deﬁnitions were ei-

ther accepted or discussed again. After two more iter-

ations all deﬁnitions were accepted and agreed upon

from both sides. The common vocabulary - reﬂect-

ing the current level of knowledge - was ﬁnally es-

tablished and committed on by all persons involved.

From this moment on, every person used only these

terms deﬁned in the common vocabulary and only ac-

cording to the common understanding.

3.2 Domain Model for the CSD Server

Domain

After deﬁning all terms and establishing a common

understanding of the core domain, the development of

the domain model for the CSD Server domain started.

Based on their actual domain knowledge, the tech-

nical experts created a ﬁrst draft version of the do-

main model. This ﬁrst draft was explained to and dis-

cussed with the domain experts. The developed do-

main model was not correct and complete in all points

and in general did not exactly represent all aspects of

the domain. The further disclosure and integration of

several new and previously not completely known de-

tails by the CSD experts led to new ﬁndings for some

terms and their relations. With the feedback of the do-

main experts and the complemented and adjusted vo-

cabulary and domain knowledge the model had been

revised by the technical experts. After several de-

velopment iterations and feedback meetings in which

the domain model was gradually updated and going

through several intermediate stages, the ﬁrst complete

and correct version of the domain model had been cre-

ated.

3.2.1 Context Map

An extract of the CSD domain model showing the

context map for the so called Catalogue Entry Stor-

age is illustrated in Figure 2 (please see Appendix).

The context map of the Catalogue Entry Storage

shows its three sub-domains represented as the pack-

ages FileManagement, CatalogueManagement and

DataModel. The package FileManagement consists

of the bounded context File. The CatalogueManage-

ment package consists of the bounded contexts Cata-

logue and CatalogueQuery. The package DataModel

contains the bounded context DataModel.

The context map deﬁnes the relations between

the mentioned bounded contexts by displaying their

shared entities. For example, the bounded con-

text File uses the shared object FileFormat and the

bounded context CatalogueQuery uses the shared ob-

ject CatalogueEntry.

3.2.2 Relation View

The relations between the bounded contexts and the

shared objects are described in relation views in fur-

ther detail. Figure 1 depicts the relations between the

shared objects File and FileFormat in the bounded

context DataModel.

Figure 1: The relation view describing the File.

The relation view shows that the File has an Id and

Data. The Data is according to a FileFormat. The

DataModel describes the FileFormat. In this way, re-

lation views help to understand the relationships be-

tween different domain model entities in connection

with the bounded contexts they belong to.

3.2.3 Process View

Process views are used to model processes in the do-

main. Processes could for example be part of business

workﬂows within the domain or technical processes

taking place between systems. Figure 3 (please see

Elaboration of a Domain Model for Migrating the Monolithic Software Architecture of a Data Management Server into a Microservice

Architecture

215

Appendix) visualizes the interaction between a Client,

the CatalogueEntry, the Catalogue and the FileMan-

agement.

The Client could ingest one or more ﬁles by pro-

viding a FileId and the File itself. The File is provided

using an upload mechanism. The FileManagement

stores the File and makes it available for distribution.

This step is optional and could also be executed sev-

eral times if there is more than one ﬁle to be provided.

The next mandatory step is the creation of the Cat-

alogEntry. This step is again initiated by the Client

and validated by the CatalogueEntry.

After the creation of the CatalogueEntry the

Client initiates the storage of the CatalogueEntry.

The Catalogue distributes the CatalogueEntry and af-

terwards notiﬁes all subscribers about the new Cata-

logueEntry.

4 CHALLENGES AND BENEFITS

OF USING A MICROSERVICE

ARCHITECTURE IN THE CSD

DOMAIN

Restructuring an existing system is in many cases a

system design decision as a result of a cost-beneﬁt

analysis in favor of the potential beneﬁts. But that

does not mean that there are only few problems to be

solved. Restructuring the architecture of an existing

system in an efﬁcient way does not only need a clear

vision of the target structure but also a good knowl-

edge of the existing architecture. A new structure has

to be designed by technical experts who are experi-

enced in the development of the desired structure. But

the technical experts also have to understand the do-

main the system is being used at.

In case of the data management server considered

in this paper, the underlying standard that is being im-

plemented by that server is very complex and ambigu-

ous. As a consequence, it is not sufﬁcient only to un-

derstand this standard but it is also necessary to get

a common understanding of how some aspect of the

ambiguous parts of the standard should be interpreted

in this context. Even the domain experts have to argue

about details and ﬁnally need to agree - in consulta-

tion with the technical experts - to a common inter-

pretation of the relevant aspects for the development

of the new structure.

After designing the desired target architecture a

migration path has to be elaborated. Because the re-

structuring process needs a certain amount of time in

which the software still has to be used, maintained

and developed further, in some cases a gradual alter-

ation approach with several intermediate stages is be-

ing applied. All of these intermediate stages have to

be planned and need to be aligned with the general

development plan of the software.

As described in section 3.2 the elaboration of a

domain model is an iterative and very communica-

tive process. It is a good way for technical experts

involved to get to know the domain as a whole and

also in detail. Moreover, it is a chance for the do-

main experts to learn how to formalize their domain

knowledge and to identify and eliminate ambiguities

in their own domain knowledge. The established do-

main model helps all involved persons to get used to

a potentially complex domain as easy as possible and

with the usage of an unambiguous common vocabu-

lary. Thus, even the design and development process

itself generates a valuable output, e.g., the list of terms

along with their deﬁnitions and the domain model, for

further design and development tasks.

From a more technical view a loosely coupled

software architecture following the principles of mi-

croservice architectures helps to efﬁciently maintain

and quickly adapt and roll out new versions of spe-

ciﬁc parts of the software. This is a major advantage

for a system that is constantly evolving but typically

only step-by-step and only in speciﬁc, isolated parts

of the software (the bounded contexts). While imple-

menting, testing and deploying the different parts of a

system separately the overall effort for software engi-

neering is signiﬁcantly reduced.

An important assumption to do so is that the in-

terfaces between the bounded contexts are ﬁxed and

don’t change over time.

A system consisting of such loosely coupled ser-

vices that interact with each other over ﬁxed inter-

faces provides a good basis for an implementation fol-

lowing a microservice approach.

5 CONCLUSION

The paper introduced the best practices for the devel-

opment of the domain model for a speciﬁc domain.

It started with a brief motivation why interoper-

ability is the key issue in the CSD domain and intro-

duces the goal of migrating an existing data manage-

ment server using a domain-driven design approach.

Then the typical best practice approach of work-

ing out an ubiquitous language as a basis for the cre-

ation of a domain model was presented. Afterwards,

the development of a domain model was described on

a conceptual level on one hand and on a more techni-

cal level on the other hand.

KMIS 2019 - 11th International Conference on Knowledge Management and Information Systems

216

To provide some practical experiences the con-

crete approach of elaborating a domain model for the

CSD domain was described. The concrete approach

also followed the typical steps of ﬁrst creating a ubiq-

uitous language for the CSD domain followed by the

development of several different diagrams that also

serve as examples for the previously deﬁned design

artifacts.

As a last major topic the challenges and beneﬁts of

the usage of microservices in the CSD domain were

pointed out.

REFERENCES

Evans, E. (2003). Domain-Driven Design – Tackling Com-

plexity in the Heart of Software. Addison-Wesley.

Evans, E. (2015). Domain-Driven Design Reference – Def-

initions and Pattern Summaries. Dog Ear Publishing.

Landre, E., Wesenberg, H., and Olmheim, J. (2007). Agile

enterprise software development using domain-driven

design and test ﬁrst.

Millett, Scott with Tune, N. (2015). Patterns, Principles,

and Practices of Domain-Driven Design. John Wiley

& Sons, Inc.

(NSO), N. S. O. (2018). STANAG 4559 Edition 4.

Vernon, V. (2013). Implementing Domain-Driven Design.

Addison-Wesley.

Zaschke, C., Essendorfer, B., and Kerth, C. (2016). Interop-

erability of heterogeneous distributed systems. In Sen-

sors, and Command, Control, Communications, and

Intelligence (C3I) Technologies for Homeland Secu-

rity, Defense, and Law Enforcement Applications XV,

volume 9825, page 98250Q. International Society for

Optics and Photonics.

Elaboration of a Domain Model for Migrating the Monolithic Software Architecture of a Data Management Server into a Microservice

Architecture

217

APPENDIX

Figure 2: An extract of the CSD domain model showing the context map for the Catalogue Entry Storage.

Figure 3: The process view describing the ingest process.

KMIS 2019 - 11th International Conference on Knowledge Management and Information Systems

218