Domain-Driven Design in Microservices-Based Systems Development: A Systematic Literature Review and Thematic Analysis

Abstract

With the increment in software development complexity, approaches such as domain-driven design (DDD) are needed to tackle contemporary business domains. DDD is already being used in various software projects with different architectural styles. Evidence in the literature suggests using DDD to mitigate challenges in the Microservices Architecture style. Although some studies have explored the decomposition of business domains or legacy monolithic systems into microservices, there is a lack of concrete information regarding the practical implementation of DDD in this architectural style. This has led to ambiguity regarding the use of DDD in developing microservices-based systems. The paper systematizes findings on the purpose of using DDD, its patterns, associated technologies, and techniques. A systematic literature review of 35 articles was conducted. Thematic analysis was employed to identify five high-order themes and 11 themes. Based on our analysis, we have concluded that microservice identification emerges as the primary motivation behind developers' adoption of DDD. However, it is important to note that this utilization manifests with variations across the literature. Finally, our analysis found several challenges and benefits in the use of DDD in microservices development.

INTRODUCTION

This paper is an extension of work initially presented at the 11th International Conference in Software Engineering Research and Innovation (CONISOFT 2023) [1]. The original study is a systematic mapping study on domain-driven design (DDDS) for Microservices Architecture Systems Development. In this paper, we conducted a comprehensive systematic literature review and employed thematic synthesis to identify and analyze patterns in the uses of DDD in this context. This study synthesizes the findings from a broader range of primary studies and search strategies.

Since the release of Eric Evans’ book “The Blue Book” in 2004 [2], a community of practitioners has emerged who explore the use of DDD and patterns in different software development projects. DDD can be understood as an approach that addresses the complexities of a business by emphasizing the team’s focus on domain knowledge [2]. Some authors [3]– [5] have proposed patterns and techniques to analyze business domains and incorporate that knowledge into software projects.

DDD patterns can be classified as strategic and tactical designs, which are the key elements of this approach. Strategic design involves domain analysis and decomposition. On the other hand, tactical design translates the knowledge acquired from strategic design into actual lines of code [4]. Practitioners have incorporated domain decomposition, effective communication, and other DDD concepts in different software development processes with diverse architectural styles. Although DDD patterns and techniques can be applied to any architectural style, DDD has gained attention in Microservices Architecture (MSA). According to Fowler, M. and Lewis, J., MSA is “A particular way of designing software applications as suites of independently deployable services.” [6]. Each microservice should exhibit a specific set of properties [6, 7]. These properties are related to each service’s modularity, cohesion, and coupling.

When applying MSA in practice, developers have encountered a range of challenges in achieving the desired properties of this architectural style [8–11]. Authors have classified these challenges into organizational, design, and technical challenges [9, 10]. However, the frequency at which these challenges are mentioned varies. For example, the identification of microservices is a key challenge, sometimes considered the most critical according to some authors [10, 11]. The granularity of microservices directly impacts MSA’s quality characteristics, such as maintainability and availability. Another frequently mentioned challenge is effective communication among stakeholders, which impacts the efficacy of the software development process [9], [11]. Finally, technological complexity is another major challenge mentioned by authors, among others.

Based on the challenges highlighted by various authors concerning MSA, several studies aim to reduce the complexity in the development of microservices-based systems. While some proposals have been put forth to address these challenges, no definitive solution has emerged. However, the use of DDD has been featured prominently in these proposals. This connection between DDD and MSA can be traced back to the 2014 definition of MSA, and the principles of DDD have frequently been referenced within microservices.

Books such as Learning Domain-Driven Design by Vlad Khononov [4] and Building Microservices by Sam Newman [7] delve into the relationship between DDD and microservices. One of the key connections between DDD and MSA lies in the concept of decomposition, employing patterns like bounded context (BC) or subdomains. DDD has been viewed as a means of mitigating the challenges MSA poses in the design of microservices-based systems. Some authors [12], [13] have reported the frequent use of DDD for tacking the complexity of some challenges related to the design and deployment of microservices-based systems, where opportunity areas have been mentioned to obtain a domain-oriented design for microservices that reflects the business logic organization. However, despite theoretical discussion [7], [14] of the relationship between these approaches, uncertainties have surrounded their practical application. Additionally, the challenges associated with MSA [9], [11], combined with those of DDD [14], have given rise to new challenges in the practical implementation of microservices development with DDD. This lack of clarity regarding DDD for microservices development has created a gap between theory and practice.

The issue concerning the knowledge gap between the theory and practice of DDD is directly tied to the practical advantages it offers in designing microservices-based systems. In some studies, [15], [16], a set of strategies and techniques to design APIs have been reported to deal important decisions about microservices, where the granularity definition of microservices has been one of the most important themes around mentioned architecture. However, various ideas, patterns, and techniques within DDD have often been cited concerning achieving mentioned benefits related to well-defined granularity for microservices. Moreover, incorporating DDD principles suggests enhanced efficiency in stakeholder collaborative work [13]. The mentioned benefits of DDD are examples of potential solutions for microservices challenges, which are hindered by the lack of knowledge about the use of DDD principles and patterns in a practical context.

The potential of DDD, as highlighted in various books, can enhance the effectiveness of a microservices-based solution. Additionally, DDD can provide insights into determining the optimal size of a microservice, which is a critical aspect of MSA and sets it apart from other architectural styles. While the literature mentions numerous areas of opportunity for adopting DDD in microservices design, the dispersion and uncertainty surrounding practical DDD knowledge raise questions about the feasibility of realizing all the theoretical benefits of combining MSA with DDD in practical contexts.

This lack of clarity can be mitigated by analyzing practical cases documented in the literature regarding the utilization of DDD in the development of microservices-based systems. While other studies have addressed this issue, none provide specific reasons for authors' decisions to employ DDD in microservices development and the corresponding outcomes. Among these unexplored aspects, it is crucial to determine the DDD techniques employed, identify the patterns utilized in microservices design, and explore other pertinent details that shed light on the limitations and areas of opportunity in using DDD for microservices-based development.

To better understand the practical use of DDD in developing microservices-based systems, this study extends our previously systematic mapping study [to be published]. We conducted a systematic literature review complemented with a thematic analysis. The objective was to investigate the current state of the art in microservices development with DDD in practical scenarios. We compiled and analyzed a collection of diverse studies that reported the use of DDD in their microservices projects from 2014 to 2023. The findings obtained from this evidence can assist developers in identifying the practical applications and adaptations made by their peers when utilizing DDD. Furthermore, this research can also help uncover DDD’s limitations and identify areas of opportunity where this approach can effectively address the main challenges associated with microservices development.

This study is organized as follows: Section 2 provides an overview of the related work in this field. Section 3 outlines the research method chosen for conducting the systematic literature review. The execution of this research method is described in Section 4. The results obtained from the research method are presented in Section 5, followed by a discussion in Section 6. Section 7 addresses the potential threats to the validity of this study. Finally, Section 8 presents the conclusions drawn from the evidence collected in this research.

RELATED WORK

This section provides an overview of the research work associated with the objective of this study. Several papers have conducted an analysis process to delve into various aspects of microservices-based systems and domain-driven design (DDD) individually. Specifically, these studies have shed light on the challenges encountered in microservices design and the difficulties faced in implementing DDD principles [14], [17]. However, it is worth highlighting that only two studies examine the intersection of DDD and microservices architecture (MSA).

In a study by Singjai et al. 2021 [18], the authors investigated architectural design decisions (ADD) associated with API design and DDD patterns using a grounded theory research method. The APIs developed using DDD served as the foundation for modeling microservices. Specifically, Singjai et al. identified six ADDs and 27 decision options about utilizing the DDD domain model and strategic patterns for delineating API specifics. It is important to note that this study was limited to gray literature and did not analyze white literature sources. Singjai et al. acknowledged the risk of generalizing their findings, underscoring the potential for additional resources in different data sources relevant to the research topic.

Schmidt et al. also conducted a relevant study in 2020 [19], which entailed a systematic literature review focused on microservices identification proposals. This study examined two distinct development approaches: model-driven development (MDD) and DDD. The authors collected a set of primary studies from 2013 to 2019, of which 27 were considered for review. Among these 27 primary studies, only four included DDD patterns specifically for microservices identification. While the study primarily focused on white literature, it did not specifically address the examination of DDD and MSA practices as its main objective. Given the time frame covered by Schmidt et al. and the recent surge in research highlighting the relationship between DDD and MSA, as mentioned in various studies [20]– [22], there arises a clear need for a dedicated study that concentrates on the utilization of DDD within the context of developing microservices-based systems.

This study will solely encompass white literature to narrow the research scope and delve into previously unexplored evidence of the integration of DDD and MSA. By concentrating solely on white literature, we aim to complement existing related work and provide an analysis of DDD’s application in developing microservices-based systems.

RESEARCH METHOD AND CONDUCTION

This section describes the method followed for our systematic literature review. Firstly, we followed the Kitchenham proposal [23] for evidence-based research on software engineering. This method is shown in Fig. 1, beginning with creating a systematic literature review protocol for research. In addition, other methods were selected to complement some phases and activities of the research.

Fig. 1. [Images not available. See PDF.]

Research method by Kitchenham.

The methods used to complement the systematic literature review were: (I) Automatic search with Zhang et al. proposal [24], (II) Snowballing process proposed by Wohlin [25], (III) Narrative synthesis from Popay et al. proposal [26], and (IV) Thematic synthesis from the proposal of Cruzes & Dyba [27]. To complement the analysis with thematic synthesis, some guidelines of the Thematic analysis method proposed by Clark & Braun [28] were performed in this study.

Search Process

We started following Phase 1 of the systematic literature review method proposed by Kitchenham. We chose the mentioned method over others, such as the purpose of Moher and Liberati [29], because of the focus on the Software Engineering (SE) discipline and its proven use in various secondary studies in that discipline. The emergence of the evidence-based movement and, specifically, the systematic literature review method allowed us to expand the knowledge of SE through a rigorous, reliable, and systematic approach, according to Kitchenham [23].

Following Kitchenham’s method, we defined and refined a set of research questions (RQ) during the research process. These RQs were documented in a systematic literature review protocol [30] and uploaded in Zenodo. We can see these RQs in Table 1.

Table 1. . Research questions

Research question	Motivation
RQ-1. What are the purposes of using DDD for microservices-based systems development?	Identify the reasons why authors use DDD in their microservices projects
RQ-2. What is the evidence about the use of DDD for microservices-based systems development?	Collect how authors mentioned the use of DDD
RQ-3. What DDD patterns are used in the microservices-based systems development?	Identify the design patterns of DDD used by authors of primary studies and the details about its use
RQ-4. What technologies are used with DDD for microservices-based systems development?	Extract possible technologies that could complement DDD in the microservices development
RQ-5. What techniques are used with DDD in microservices-based systems development?	Identify DDD techniques used in microservices-based systems development or techniques used to complement DDD
RQ-6. What challenges are mentioned by authors during the development of microservices-based systems?	Identify the difficulties faced by authors in the practice of DDD during their developments
RQ-7. What proposals exist for the development of microservices-based systems with DDD?	Identify proposals used to mitigate the challenges in the use of DDD for microservices-based systems development

These RQs were guidelines for the research process and the key criteria for discarding or selecting papers during the search process.

(1) Manual search. The first step in the search process was to find relevant studies by searching for terms related to the research topic in Google Scholar1. This manual search allowed us to identify search engines with relevant publications for the research topic and conferences, journals, or workshops with studies that answered at least one RQ. After the manual search, 18 relevant studies were identified.

These relevant studies were the basis for performing an automatic search. We chose the proposal from Zhang et al. [24] to create a search string that facilitates the identification of primary studies on different engines. The automatic search method of Zhang et al. is closely related to systematic literature review studies [23], and the proposal of strict metrics to evaluate the quality of a search string (Recall and Precision) reduces the likelihood of missing relevant studies. This chosen method is shown in Fig. 2.

Fig. 2. [Images not available. See PDF.]

Steps to find relevant studies of Zhang et al. [23].

Following the automatic search proposal by Zhang et al., the relevant studies found from manual search formed the quasi-gold standard (QGS) [24]. At the same time, some key concepts were extracted from the mentioned studies to build a search string.

The relevant studies identified after manual search were published in the following databases: IEEE Xplore, ACM Digital Library, ScienceDirect, and SpringerLink. Therefore, these databases were used in the automatic search, and based on the number of relevant studies identified and the ranking presented in Zhang et al.’s paper, the IEEE Xplore was selected for the search string evaluation proposed in Zhang et al.’s method.

With 18 studies that conformed to the QGS and IEEE Xplore selected as the evaluation engine, we evaluated different versions of the search string with the formulas proposed by Zhang et al. These formulas shown in (1,2) gave us a metric to move on to the automatic search. The Recall is equal to the percentage of the division of the number of relevant studies (RS) obtained with the search string by the sum of All Studies (AS) that form the QGS. On the other hand, Precision is a percentage of the division of the RSs obtained with the execution of the search string by all the studies (relevant or not) obtained before the execution of the search string.

1

2

Following the recommendations of Zhang et al. [24], the search string was only approved when its recall was at least 80%. Several iterations of search string evaluation were performed; some of the search strings evaluated are shown in Table 2 of the Annexes section.

Table 2. . Examples of evaluated search strings

ID	Search string	Recall	Precision
SS01	(“Domain-driven design” OR “domain driven design” OR “DDD” OR “bounded context” OR “decompos*") AND ("microservice*" or "micro-service” OR “API” OR “REST API”)	39.06%	48.13%
SS02	(“Domain-driven design” OR “domain driven design” OR “DDD” OR “DDD pattern”) AND (“microservice” OR “microservices” OR “micro-service” OR “decompose” OR “decomposition”)	82.35%	45%
SS03	(“Domain-driven design” OR “domain driven design” OR “DDD pattern”) AND (“microservice” OR “microservices” OR “micro-service” OR “decompose” OR “decomposition”)	92.15%	38.05%

The acronym used to identify the search strings (SS) refers to “Search String” and is followed by the number of identifications. As shown in Table 2, SS03 was selected over SS02 due to the high recall, even when the precision was lower than SS02. This could be translated as the preference to find more studies relevant to the research topic through denser filtering of studies (Recall) instead of avoiding the filter of fewer studies with fewer relevant studies (Precision). This search string (SS03) was executed in the engines selected for automatic search, and the papers obtained after the automatic search on each engine were filtered.

Selection Process

Once the search string was built, we established inclusion and exclusion criteria based on the characteristics of primary studies that formed the QGS. These selection criteria are shown in Table 3. The period between 2014 and 2023 was considered due to the publication of the first definition of microservice architecture. This definition was published by Martin Fowler and James Lewis in 2014 [6], together with some of the characteristics that MSA should have. With these selection criteria, the papers obtained from the execution of the search string were filtered to identify the primary studies.

Table 3. . Selection criteria

Inclusion criteria	Exclusion criteria
IC-01. The study is published between 2014 and 2023	EC-01. The study is not a conference, journal, or workshop paper
IC -02. The study is published in English	EC-02. The study is not accessed with an institutional account
IC -03. The study’s title seems to answer at least one research question.	EC-03. The study is not related only to the specific use of Domain-Driven Design in the context of Microservices Architecture.
IC-04. The study’s resume seems to answer at least one research question.	EC-04. The study is duplicated
IC -05. The full text of the study answers at least one research question.

For the filter process, the selection criteria shown in Table 3 were grouped into phases. Each phase with the group of selection criteria is shown in Fig. 3. The grouping was made considering the filtering tools of the selected engines. Based on Fig. 3, Stage 1 was performed through the year and type filters of engines selected.

Fig. 3. [Images not available. See PDF.]

Filtering process.

Stage 2 grouped exclusion criteria related to the access of papers and the duplicated studies between engines. This duplication was identified mainly between ACM Digital Library and IEEE Xplore, where four duplicated studies were found during the manual search. Stage 3 involved the reading of the title and abstract of each paper. Lastly, in Stage 4, the papers were downloaded and read to confirm that the content answered at least one RQ.

As a result of the selection process, some papers were included and excluded through different stages. This filtering process is shown in Fig. 4.

Fig. 4. [Images not available. See PDF.]

Filtering process through selection criteria.

As shown in Fig. 4, a sum of 624 studies was collected from the execution of search strings in all engines. After Stage 1, 357 studies were filtered. In Stage 2, 155 studies were discarded. After Stage 3, 79 studies were discarded, obtaining 123 relevant studies. As a result of Stage 4, 31 primary studies were identified.

Snowballing Process

After the selection process, 31 primary studies were identified. However, some primary studies could have been omitted during the selection process, so we decided to perform a snowballing process. We chose the process proposed by Wohlim [25]. This method proposes a systematic selection based on the relationship between studies through their references, which allows the division of the entire process into backward and forward. Firstly, we performed a backward snowballing. This process consisted of extracting all references of primary studies to filter and identify relevant studies omitted in the automatic search.

The selection process applied to the references of primary studies in backward snowballing execution is shown in Fig. 5.

Fig. 5. [Images not available. See PDF.]

Backward snowballing.

As shown in Fig. 5, 381 papers were extracted from the references section of the 31 primary studies identified after automatic search. Only three of the 381 primary studies candidates were chosen after filtering. However, a second iteration of backward snowballing was performed by taking as input the three primary studies identified in the first iteration of backward snowballing. A sum of 20 papers were extracted from the references of the three primary studies mentioned above. However, no primary study was identified in the second iteration, finishing the backward snowballing.

Table 4. . Primary studies

ID	Title	Authors	Year	DOI
PS-01	A cloud-native online judge system	Guan-Chen Pan, Pangfeng Liu, and Jan-Jan Wu	2022	10.1109/COMPSAC54236.2022.00204
PS-02	A hot decomposition procedure: operational monolith system to microservices	Nikolay Ivanov and Antoniya Tasheva	2021	10.1109/ICAI52893.2021.9639494
PS-03	A systematic framework of application modernization to microservice-based architecture	Munezero Immaculee Joselyne, Gaurav Bajpai, and Frederic Nzanywayingoma	2021	10.1109/ICEET53442.2021.9659783
PS-04	Conformance assessment of architectural design decisions on the mapping of domain model elements to APIs and API endpoints	Apitchaka Singjai and Uwe Zdun	2022	10.1109/ICSA-C54293.2022.00058
PS-05	Deriving microservice code from underspecified domain models using DevOps-enabled modeling languages and model transformations	Florian Rademacher, Sabine Sachweh and Albert Zündorf	2020	10.1109/SEAA51224.2020.00047
PS-06	Designing a next-generation continuous software delivery system: Concepts and architecture	Andreas Steffens, Horst Lichter, and Jan Simon Döring	2018	10.1145/3194760.3194768
PS-07	Enterprise service application architecture based on domain driven model design	Yu Ding, Shaokun Li, JianWei Zhang, LiLing Wang, and XuTong Wang	2020	10.1109/ITCA52113.2020.00167
PS-08	Extending the SEMAT kernel for the practice of designing and implementing microservice-based applications using domain driven design	Parthasarathi Ray and Pinakpani Pal	2020	10.1109/CSEET49119.2020.9206200
PS-09	Microservice decomposition via static and dynamic analysis of the monolith	Alexander Krause, Christian Zirkelbach, Wilhelm Hasselbring, Stephan Lenga, and Dan Kr¨oger	2020	10.1109/ICSA-C50368.2020.00011
PS-10	Microservice migration using strangler fig pattern: A case study on the green button system	Chia-Yu Li, Shang-Pin, and Tsung-Wen Lu	2020	10.1109/ICS51289.2020.00107
PS-11	Microservices-based IoT monitoring application with a domain-driven design approach	Alam Rahmatulloh, Dewi Wulan Sari, Rahmi Nur Shofa, and Irfan Darmawan	2021	10.1109/ICADEIS52521.2021.9701966
PS-12	Partitioning microservices: A domain engineering approach	Munezero Immaculée Josélyne, Doreen Tuheirwe-Mukasa, Benjamin Kanagwa, and Joseph Balikuddembe	2018	10.1145/3195528.3195535
PS-13	SDN applications - The intent-based Northbound Interface realization for extended applications	Minh Pham and Doan B Hoang	2016	10.1109/NETSOFT.2016.7502469
PS-14	Towards a methodology for creating Internet of Things (IoT) applications based on microservices	Edwin Cabrera, Paola.Cárdenas, Priscila Cedillo, and Paola. Pesántez-Cabrera	2020	10.1109/SCC49832.2020.00072
PS-15	Model-based engineering for microservice architectures using enterprise integration patterns for inter-service communication	Roland Petrasch	2017	10.1109/JCSSE.2017.8025912
PS-16	A microservice architecture for the Industrial Internet-Of-Things	Jürgen Dobaj, Jürgen Dobaj, Michael Krisper, and Christian Kreiner	2018	10.1145/3282308.3282320
PS-17	Advanced domain-driven design for consistency in distributed data-intensive systems	Susanne Braun, Annette Bieniusa, and Frank Elberzhager	2021	10.1145/3447865.3457969
PS-18	Domain driven design and provision of micro-services to build emerging learning systems	Maha Khemaja	2016	10.1145/3012430.3012643
PS-19	Using public and free platform-as-a-service (PaaS) based lightweight projects for software architecture education	Zheng Li	2020	10.1145/3377814.3381704
PS-20	Domain-driven design applied to land administration system development: lessons from the netherlands	Peter Oukes, Marc van Andel, Erwin Folmer, Rohan Bennett, and Christiaan Lemmen	2021	10.1016/j.landusepol.2021.105379
PS-21	SPReaD: Service-oriented process for reengineering and DevOps	Carlos Eduardo da Silva, Yan de Lima Justino, and Eiji Adachi	2022	10.1007/s11761-021-00329-x
PS-22	Migrating monolithic mobile application to microservice architecture: An experiment report	Chen-Yuan Fan and Shang-Pin Ma	2017	10.1109/AIMS.2017.23
PS-23	Designing a smart city internet of things platform with microservice architecture	Alexandr Krylovskiy, Marco Jahn, and Edoardo Patti	2015	10.1109/FiCloud.2015.55
PS-24	Design of domain-driven microservices-based software talent evaluation and recommendation system	Kun. Zhang, Ji Tian, Qin Yuan, and Jing Han	2022	10.1109/ICEKIM55072.2022.00076
PS-25	Sharing platform of digital specimen of wood canker based on WebGIS in Xinjiang province: Architecture, design and implementation	Quansheng Li, Wei Sun, and Rong Ma	2022	10.1109/CIPAE55637.2022.00029
PS-26	A reference architecture for the operationalization of machine learning models in manufacturing	Tim Raffin, Tobias Reichenstein, Jonas Werner, Alexander Kuhl, and Jorg Franke	2022	10.1016/j.procir.2022.10.062
PS-27	Towards a multi-tenant microservice architecture: An industrial experience	Cesar Batista, Bruno Proença, Everton Cavalcante, Thais Batista, Felipe Morais, and Henrique Medeiros	2022	10.1109/COMPSAC54236.2022.00100
PS-28	Domain-driven design as model contract in full-stack development	Christoph Praschl, Sophie Bauernfeind, Christian Leitner, and Gerald A. Zwettler	2023	10.1109/ICECCME57830.2023.10252654
PS-29	Designing service oriented architecture model in sehatin application with a domain-driven design approach	Nilo Legowo, Erin, Eugenius Hansel Lee, and Merryta Djakaria	2023	10.1109/ICIMTech59029.2023.10278057
PS-30	Architecting digital twins using a domain-driven design-based approach	Aurora Macías, Elena Navarro, Carlos E. Cuesta, and Uwe Zdun	2023	10.13039/501100011033
PS-31	An approach to clean architecture for microservices using python	Isha V P and Vishalakshmi Prabhu H	2023	10.1109/CSITSS60515.2023.10334229
PS-32	A DDD approach towards automatic migration to microservices	Malak Saidi, Anis Tissaoui, and Sami Faiz	2023	10.1109/IC_ASET58101.2023.10150522
PS-33	Actor-driven decomposition of microservices through multi-level scalability assessment	Matteo Camilli, Carmine Colarusso, Barbara Russo, and Eugenio Zimeo	2023	10.1145/3583563
PS-34	Refactoring with domain-driven design in an industrial context: An action research report	Ozan Özkan, Önder Babur, Mark van den Brand	2023	10.1007/s10664-023-10310-1
PS-35	Migrating monoliths to cloud-native microservices for customizable SaaS	Espen Tønnessen Nordli, Sindre Grønstøl Haugeland, Phu H. Nguyen, Hui Song, and Franck Chauvel	2023	10.1016/j.infsof.2023.107230

To finish the snowballing process according to the recommendations of Wohlim [25], forward snowballing was performed based on the 34 primary studies identified, where 31 come from the automatic search process and three from the backward snowballing. This selection process is shown in Fig 6.

Fig. 6. [Images not available. See PDF.]

Forward snowballing.

Table 5. . Technologies used with DDD for microservices-based systems development.

Technology name	Description	Primary studies	Official web site
Eclipse Papyrus	Design environment used by authors for code derivation from a DDD domain model made with a UML Profile	PS-05	https://eclipse.dev/papyrus/
ExplorViz	The 3D tool used by authors to identify coupling degrees between BCs (microservices).	PS-09	https://explorviz.dev/
Structure 101	Static code analysis tool used to scan a legacy monolithic project and obtain BC candidates.	PS-09	https://structure101.com/

A sum of 275 studies that reference the 34 primary studies were found. After filtering, one primary study was identified, finishing the forward snowballing. At the end of the snowballing process, 35 primary studies were identified, and these studies formed all the evidence collected by this study for performing the data analysis.

Data Extraction Process

Following the recommendations of Kitchenham for a systematic literature review, we performed a preliminary synthesis based on the proposal of Popay et al. [26] to identify the answers to the RQs. We performed only some steps of narrative synthesis to confirm that each primary study answered at least one RQ. This preliminary synthesis also allowed us to familiarize ourselves with the content of primary studies. This familiarization phase is one of the first steps of thematic synthesis [27].

Table 6. . Themes and subthemes of thematic synthesis.

Higher-order theme	Theme	Definition
Cross-stakeholders communication	Ubiquitous domain language	This theme refers to the communication between domain experts and the development team through a common language based on business vocabulary. Not all business terms are used during communication between domain experts and developers; only the key terms are used to understand the business problem. Primary studies: PS-03, PS-07 - PS-09, PS-10 - PS-12, PS-20, PS-27
	Domain terminology discovery	This theme refers to elicitation and DDD techniques used to identify the key terms from business to conform to the ubiquitous language. Primary studies: PS-03, PS-08 - PS-09, PS-11 - PS-12
Microservices identification	Domain decomposition	This theme involves decomposing a domain into smaller partitions corresponding to a subdomain or bounded context. Each domain partition was treated as a microservice during the design phase. Primary studies: PS-01 - PS-03, PS-06 - PS-15, PS-16 - PS-27, PS-29 - PS-32
	Domain data flow analysis	This theme refers to analyzing domain data exchange between different entities to identify clusters transformed into aggregates or BCs (microservices candidates). Primary studies: PS-01, PS-07 - PS-08, PS-10, PS-20 - PS-21
Microservices architecture design	Domain model-based microservice design	This theme refers to modeling microservices architecture with a domain model comprising domain objects. A microservice is designed based on different types of DDD domain objects (entities, value objects, aggregate roots, and others) and their relationships drawn in a domain model. Primary studies: PS-01 - PS-05, PS-07 - PS-08, PS-10 - PS-12, PS-14 - PS-17, PS-20, PS-26 - PS-28, PS-30 - PS-32
	Detailed microservices design	This theme refers to the decisions made based on the technical aspects of microservices implementation. This occurs once microservices candidates have been identified with DDD, and different design patterns and UML artifacts are used to refine the design obtained with DDD. Primary studies: PS-03 - PS-07, PS-09 - PS-11, PS-14 - PS-15, PS-20 - PS-24, PS-32
	Design support technologies	This theme refers to adopting technological tools to facilitate the transition from microservices design to code. Primary studies: PS-05, PS-09 - PS-11
Challenges	Domain model implementation obstacles	This theme refers to the lack of technical details of domain models obtained with DDD, which implies an unclear idea of how to implement the microservices. Primary studies: PS-03 - PS-05, PS-07 - PS-09, PS-15, PS-33
	The inherent complexity of domain-driven design	This theme refers to conditions and lack of strict steps to apply DDD “correctly” and the necessity of using skill, experience, and criteria to apply some DDD principles without overcomplex the microservices design process. Primary studies: PS-02, PS-05, PS-07 - PS-08, PS-11 - PS-13, PS-17, PS-20 - PS-22, PS-34
Benefits	Business-technical alignment advantages	This theme refers to the pros mentioned by authors of primary studies in aligning software design decisions with business logic. These benefits are related to tackling the most significant complexity during microservices design. Primary studies: PS-02, PS-04 - PS-05, PS-08, PS-10 - PS-12, PS-27, PS-30
	Microservices sizing benefits	This theme refers to the benefits of a clear business scope for microservices related to the modifiability of Microservices Architecture. Primary studies: PS-05, PS-07, PS-10 - PS-12, PS-16, PS-18, PS-20 - PS-22, PS-26, PS-29 - PS-31

The template used to extract data as part of narrative synthesis is shown in Table 7 of the Annexes section. This extraction resulted in the answers to RQs shown in Section 5.1. However, another data extraction took place once the preliminary synthesis was performed. Based on the recommendations of Cruzes and Dyba [27] and the guidelines proposed by Braund and Clark [28], another data extraction with a different format was performed.

Table 7. . Data extraction format for preliminary synthesis

ID	Extraction data
DI	Identifier
D2	DOI
D3	Title
D4	Authors
D5	Year
D6	Engine
D7	Publication type [Conference, Journal, Workshop]
D8	Venue
D9	Keywords
D10	Abstract
D11	DDD usage purpose mentioned to answer RQ1
D12	Systems where DDD is used to answer RQ2
D13	Artifacts where DDD is represented or artifacts used together with DDD to answer RQ2
D14	DDD patterns reported by authors during microservices-based systems development to answer RQ3
D15	Technologies related to DDD mentioned in each system development to answer RQ4
D16	Techniques mentioned in each system development to answer RQ5
D17	Challenges mentioned by authors in the use of DDD during microservices-based systems to answer RQ6
D18	Proposals for microservices-based systems developments with DDD to answer RQ7

The first format is shown in Table 8 of the Annexes section, and it was used to collect all the text segments that answered at least one RQ by labeling with a code label candidate. After text codification and data extraction, we used another format, as shown in Table 9 of the Annexes section, to summarize the codes, meanings, and the number of text segments that formed the concept of each code. Once codes were identified, another tabular format was used to identify themes through code grouping. For that purpose, the format of Table 10 of the Annexes section was used. Finally, the format shown in Table 11 of the Annexes section was used to group the themes and identify higher-order themes through theme grouping. All the extractions based on the above formats are shown in the Zenodo repository [30].

Table 8. . Data extraction format codes of thematic synthesis

ID	Extraction data
ID study	Identifier of primary study
Code label	The name of the candidate code that labels a specific text segment.
Extraction	Text segment that represents the concept behind a code.
Research questions related	Identifiers of RQs answered by the specific text segment

Table 9. . Codes and meanings

ID	Extraction data
Code	Name of code
Meaning	The concept description behind the code
Frequency	Number of text segments that conform to the code

Table 10. . Themes

ID	Extraction data
Theme	Name of theme
Codes	List of codes that conform to the theme
Meaning	Description of the idea behind the theme
Reflexive questions	Reflexive questions from Thematic analysis of Clark & Braun [28]

Table 11. . Higher-order themes

ID	Extraction data
Higher-order theme	Name of the themes grouping
Themes	List of themes that conform to the higher-order theme
Meaning	Description of the taxonomy behind the higher-order theme

Although the RQs were the guidelines of both data extractions, preliminary synthesis aggregated the data into RQs. In contrast, in the thematic synthesis, the data was combined, compared, and grouped into Themes to express higher-order ideas such as Cruzes and Dyba expressed in their proposal [27].

Data Synthesis

As part of Phase 2 of Kitchenham’s method is the Synthesis of research. This process is a crucial part of the analysis of evidence. Through an interpretative and systematic process, new knowledge is generated based on a set of data. However, some techniques and methods exist to generate the mentioned new knowledge. Some of the preliminary synthesis was covered by Popay´s method. However, this synthesis takes place in the aggregation synthesis mentioned by Kitchenham [23], which is not the purpose of this study. The synthesis proposed by Cruzes and Dyba [27] is closely related to our work and to the Kitchenham guidelines.

Thematic synthesis allows us to combine, compare, and explore the patterns in the data. These meaning patterns are helpful in generating new conclusions (generalizations) to achieve the aim of this study and complete Kitchenham’s method. The thematic synthesis method shown in Fig. 7 was based on the thematic analysis proposed by Braun and Clark [28], providing guidelines to explore the evidence and cover the step “Data synthesis” of the Kitchenham method.

Fig. 7. [Images not available. See PDF.]

Thematic synthesis process.

As shown in Fig. 7, the first step corresponds to familiarization with primary studies. The mentioned preliminary synthesis was also used to cover the first step. The second is identifying text segments from primary studies that answer the RQs. This second step inspired the second data extraction for thematic synthesis mentioned in Section 3.4. The third step was the label of text segments. This step was performed through coding in MaxQDA2 2020, where the codes were filled out in the tabular formats described in Section 3.4. The code labels were refined through consensus among the authors of this study.

The fourth step was the identification of themes as a set of closely related codes. Each code represents a relevant and single-faceted concept, while each theme represents a multifaceted idea [28]. Therefore, we grouped codes that explain the meaning of the same background idea. After identifying the themes, they were grouped into higher-level taxonomies (Higher-order themes). These higher-order themes related to a set of themes show the high-level overview of the data from the evidence collected. Finally, some relations between themes from different higher-order themes were identified. A discontinued line was used to indicate the relation between them. The product of the execution of the thematic synthesis method was the thematic map shown in Subsection 5.2.

RESULTS

The products obtained from the method conduction are shown in this section. These results encompass answers for RQs and a thematic map that synthesizes all data collected by this study. The primary studies identified also take place in this section; due to the extension of the results, the identified primary studies can be found in Table 4 of the Annexes section, and we will reference the primary studies by their identifier PS-XX in the rest of the study, where PS is the acronym of “Primary Study”.

As shown in Table 4, the use of DDD in microservices-based systems development has increased in recent years, where 2023 represents the year with the most significant number of primary studies published. The distribution graphic with the publication years of primary studies is shown in Fig. 8.

Fig. 8. [Images not available. See PDF.]

Primary studies by publication years.

Regarding the engines where primary studies were published, the IEEE Xplore was the engine where the major number of primary studies were found, with 25 primary studies published. ACM Digital Library was the second, with five primary studies published, ScienceDirect with three studies, and SpringerLink with two studies. The graphic with the number of primary studies found per engine is shown in Fig. 9.

Fig. 9. [Images not available. See PDF.]

Primary studies by engine.

Answers to Research Questions

The RQs were the guidelines of this study, and the findings obtained for each RQ enabled us to understand the state of research on the use of DDD for microservices-based systems. This section answers the research questions mainly with quantitative data and some qualitative details. However, the product of qualitative analysis is shown in Section 5.2.

(1) RQ-1: What are the purposes of using DDD for microservices-based systems development? In the use of DDD reported by authors, four motivations were identified in microservices-based systems development. These motivations are shown in Fig. 10.

Fig. 10. [Images not available. See PDF.]

Purposes of DDD usage in microservices-based systems development.

As shown in Fig. 10, almost all authors of the primary studies mentioned having used DDD for microservices identification, which consists of decomposing a business domain or legacy system into partitions corresponding to microservice candidates. For this purpose, the strategic patterns BC and subdomain were commonly used. However, strategic patterns are not the only DDD resource authors reported for microservices identification; some used DDD techniques such as context mapping [2] and event-storming [4] to draw the boundaries of each microservice based on business scope.

The second most frequent purpose by which authors chose DDD was the design of each microservice. This design took place after the microservices identification, and it refers to the definition of a domain model that reflects business knowledge isolated into each microservice. This domain model mentioned in the second purpose (referred to in this study as the DDD Domain model) comprises a set of domain objects mapped as tactical patterns used to design the business domain layer for each microservice. As shown in Fig. 10, 55.88% of authors who used DDD for microservices identification reported having designed each microservice with DDD. This statistic indicates that some authors used other design patterns and artifacts to specify the architecture of each microservice once they have been identified with DDD.

The third purpose shown in Fig. 10 was using ubiquitous language (UL) to cultivate a common language between domain experts and the development team to increase communication effectiveness. Authors who used DDD for this mentioned purpose reported facing unknown domains requiring constant feedback from domain experts. The authors also mentioned using UL to increase the effectiveness of the microservice-based systems because the microservices were developed, prioritizing a high level of comprehension of the business problem.

The fourth purpose was only identified in two primary studies. It uses a subdomain pattern to split a broad business domain into more manageable partitions. Unlike microservices identification, the use of DDD for wide domain decomposition is about reducing the complexity of the business domain through partitioning, where each part of the domain can be decomposed into several microservices.

Based on the purposes of the use of DDD by the authors of primary studies, we could identify specific DDD patterns used for each kind of purpose shown in Fig. 10. This detail collected about the purposes by which DDD has been used in microservices-system developments allowed us to notice that strategic design patterns have been used more frequently than tactical design patterns. This trend is shown in Fig. 11.

Fig. 11. [Images not available. See PDF.]

Frequency of use of tactical and strategic design.

Based on Fig. 10, in 100% of primary studies, the strategic design has been reported. On the other hand, 54.28% of primary studies contain details about the use of tactical design. This statistic means that DDD has been used mainly for domain analysis concerning an adequate microservices scope definition in terms of business logic, having a less frequent use (but no less relevant) for the detailed design of each microservice once it has been defined in scope.

(2) RQ-2: What is the evidence about the use of DDD for microservices-based systems development? The first one was software systems, and the second was models. Figure 12 shows the systems developed by authors with DDD and microservices architecture. These systems were classified into two kinds based on the details mentioned by the authors about their development process and the context of the business domain problem.

Fig. 12. [Images not available. See PDF.]

Microservices-based systems developed with DDD.

As shown in Fig. 12, DDD was used to develop 36 microservices-based systems. Of these systems, 56.76% correspond to domains controlled and limited by authors to evaluate a proposal or explore the use of some DDD patterns and principles (example systems). On the other hand, 43.24% of the mentioned systems correspond to real problems where it is necessary to satisfy the necessity of the clients (industry systems).

Furthermore, in Fig. 12, it is possible to notice that most of the system developments were from scratch, whereas 21.62% correspond to migrations, and only in one primary study (PS-34) a refactoring case of a microservices-based system with anti-patterns was mentioned. Although the example systems predominate over the industrial systems, the latter describes the use of DDD in greater detail.

On the other hand, a set of models involved in the microservices design process were identified. Some of them come from the DDD literature, but others were used to complement the design obtained with DDD, according to the authors of primary studies. In Fig. 13, a set of models is shown, classified by the type of system where the authors mentioned them.

Fig. 13. [Images not available. See PDF.]

Models used with DDD for microservices design.

Figure 13 shows two DDD artifacts used during microservices design: the DDD Domain model and context map. The domain model was presented as a class diagram where the stereotype of each class referred to the tactical pattern applied, similar to the DDD domain model shown by Vaugh Vernon [5].

Authors of primary studies used the context map, and some changes were made compared to the notation described by Evans [2]. Unlike the use of strategic patterns such as customer-supplier (CS) or anti-corruption layer (ACL) to link the bounded contexts, the authors frequently create a context map with bounded contexts linked by technical details, such as the transference protocol and data scheme, among other details. However, in a few primary studies, the authors mentioned these DDD relational patterns (CS, ACL, among others), following the notation of a context map to model their microservices as bounded contexts.

In addition, the authors of primary studies used other kinds of models from DDD literature, most of which were used to refine the design obtained with DDD for each microservice. Some UML models, such as the use cases model, class model, deployment model, microservices interaction model made with sequence diagrams, and components model, were used to complement the architecture specification of their microservices-based systems.

The database model was shown as a relational model, and some authors tend to create a relational model per BC or aggregate. However, in some migration cases, a general relational model is decomposed into a set of tables that conform to BCs. This observation allowed us to see how, in some cases, the procedure for drawing the bounded contexts in a business domain differs from the literature on DDD. Although it is expected to find the use of UL for BC delimitation [2, 4, 5], UL was not the only way to identify microservices as BCs or aggregates in practice. The mentioned database model decomposition is a clear example.

Some models were created by following a notation proposed by authors of primary studies, such as the source model and sketching rough descriptions shown in Figure 13. These artifacts do not seem to follow a clear standard or notation. However, the source model mentioned in PS-03 encompasses a custom diagram where tactical patterns are represented as a kind of class diagram with colors and without attributes or methods, while the authors of PS-03 and PS-12 showed no example of the sketching rough description.

Lastly, some artifacts were mentioned by authors; however, no examples were given. An example is the case of the actor context model and flowchart shown in Fig. 13, where although they are used during microservices design together with the DDD domain model and strategic patterns, the authors describe few details about those models.

(3) RQ-3: What DDD patterns are used in the microservices-based systems development? A sum of 12 DDD patterns was used by the authors of primary studies in their microservices-based systems design process. These patterns are shown in Fig. 14.

Fig. 14. [Images not available. See PDF.]

Domain-driven design patterns used in microservices-based systems development.

Based on Fig. 14, strategic patterns were mentioned mainly in industry systems, while tactical patterns predominate in example systems. This data distribution is explained due to the challenges some authors face during analysis and familiarization with unexplored business domains in the industry context, unlike example systems, where domain complexity is controlled and limited to a particular purpose.

Figure 14 shows BC as the DDD pattern most frequently mentioned in primary studies. This pattern was treated as a microservice representation, and such as the definition by Evans [2], it delimits the scope of a model. However, although BC results from ubiquitous language (UL) manifestation according to the literature of DDD [2]– [4], some authors used BC without UL. For example, in the primary study PS-22, the authors decomposed the database of a monolith, and the database entities that were closely related were used to define the BCs. In primary studies PS-11 and PS-13, authors identified a set of functional requirements that were grouped into BCs. Another example was mentioned in PS-09, where authors used use cases to establish the scope of each BC and refine their microservices boundaries. Therefore, although 80% of primary studies where BC was used comprised a BC as a semantic boundary closely related to UL, some authors defined BCs with other design resources (use cases, classes, and others) instead of domain objects extracted by UL.

This discrepancy is not the only difference between the theory and practice of DDD. Subdomain was mentioned in PS-12 and PS-13 as a partition of the business domain. This partition was discovered by authors, following Evans’ definition [2]. However, in the rest of the studies where the Subdomain pattern was used, each subdomain was understood as synonymous with BC and, therefore, as synonymous with a microservice candidate.

The UL pattern was used by authors of primary studies to increase the effectiveness of communication between domain experts and the development team, enabling a clear understanding of the problem. In addition, it is one of the patterns (together with Subdomain, ACL, and CS) that was only mentioned by authors who developed an industry system.

Regarding tactical patterns, they were presented in a DDD domain model to obtain a domain-oriented microservices design. Entity was the tactical pattern most frequently mentioned by authors of primary studies, and it was not always related to the Aggregate pattern. Entity was used under the same definition of Evans [2] as a domain object, which has an identifier in the business domain that allows tracing its thread of continuity through data changes. Some authors of primary studies used Entity as a build unit for BCs without involving aggregates. However, other authors mentioned having used entity only in aggregates.

Unlike entity, aggregate is a pattern that requires using entity and, optionally, other patterns such as value object, domain service, repository, and others. The authors mentioned aggregate as a cluster of cohesive domain objects, with an entity that acts as an aggregate root. Similar to DDD literature, the aggregate root is responsible for maintaining strong transactional consistency in the aggregate. Furthermore, in primary studies PS-03, PS-05, PS-10, and PS-20, authors use one aggregate per BC, where each aggregate isolates a set of domain objects with at least one entity as aggregate root. Although it is possible to have more than one aggregate per BC (such as in example systems), it is expected to find a range between one and two aggregates per BC in industry systems designs.

Value object and domain service were mentioned only as building blocks of the aggregate pattern. Value object was mentioned as a replaceable domain object with no identity in the business domain and helps for entity describing, such as Evans described it [2]. Domain service was also used under the definition provided by Evans and Vernon [3, 5], where domain service encapsulates complex domain logic that is not assignable for a specific entity or value object.

Another pattern used with aggregate was repository, which was responsible for manipulating persistent data of an aggregate through ACID transactions (atomicity, consistency, isolation, and durability). Event-sourcing was a pattern mentioned during the DDD design, but no details were given about its usage in the microservices design. All tactical patterns described until now have taken place in a DDD domain model to design the business and infrastructure layer of the microservices. However, the specific use of event-sourcing in microservices design is unknown.

As shown in Fig. 14, some relational strategic patterns such as ACL and CS have been mentioned by authors of primary studies during the specification of communication strategy between BCs. However, even when authors mentioned using a context map and BC patterns, using the mentioned relational patterns for specifying BCs data exchange is not common. Instead, authors use the domain event pattern and technical details (protocol, scheme, and others) to describe BCs (microservices) interaction.

As a resume of the content of Fig. 14, BC is the pattern authors chose to model microservices, followed by subdomain and aggregate. Some modeled microservices (BCs) are designed using tactical patterns (UL terminology). However, other authors do not use UL or tactical patterns as building blocks of BCs; they use BC as a semantic boundary to limit the scope of their design artifacts, such as use cases, class models, requirements, or database entities.

(4) RQ-4: What technologies are used with DDD for microservices-based systems development? As reported by the authors, a set of technologies was identified in the microservices-based systems developments with DDD. These technologies were classified into the treemap shown in Fig. 15 of the Annexes section and into implementation and design technologies.

Fig. 15. [Images not available. See PDF.]

Technologies used in microservices-based systems designed with DDD.

As shown in Fig. 15, most of the technologies were used to implement microservices-based systems. These technologies were grouped according to their purpose in development. In the treemap shown in Fig. 15, we can find the names of technologies and the number of microservices-based systems developed using the mentioned technology. In these systems designed with DDD and which commonly followed Layered Architectural Styles, the use of REST predominates as an approach for implementation.

Although other patterns and communication strategies were used, such as Brokers (Kafka and RabbitMQ) or Sockets, HTTP 1.1 is the most common communication protocol reported by authors of primary studies. With HTTP 1.1, JSON has been the data scheme authors prefer to share data among the microservices identified with DDD. Until now, authors of the microservices-based systems collected in this study have not mentioned the use of technologies related to HTTP 2, such as Grpc3 or some transfer mechanism that supports binary codification of data to increase the performance of the software systems.

The mentioned characteristic of the microservices projects allowed us to notice that although Grpc is frequently mentioned around microservices development, the systems covered in this study tend to use compatible technology of Java (Spring), .NET, and others, which enable the maintainability, security, among other architectural characteristics. Some themes related to the performance were dealt with with other strategies, such as event-driven architecture with Brokers or multiple instances of microservices with specific deployment platforms.

Based on Fig. 15, the programming language most used in microservices implementation was Java with the Spring framework, utilizing various persistence technologies, with PostgreSQL being the most frequently mentioned. However, although several technologies were used during implementation, only three were reported as complements of the design with DDD. They are shown in Table 5.

As shown in Table 5, two technologies were used during BC analysis (ExplorViz and Structure101), where authors mentioned the possibility of using visualization tools to facilitate the analysis of a system composed of many BCs. Eclipse papyrus was used to create custom diagrams based on a UML profile, enabling the ability to generate code directly from a DDD domain model.

(5) RQ-05: What techniques are used with DDD in the microservices-based systems development? The techniques of DDD used to complement DDD identified during the microservices-based systems development are shown in Fig. 16.

Fig. 16. [Images not available. See PDF.]

Techniques used together with DDD.

As shown in Fig. 16, the authors used two kinds of techniques during the microservices design: elicitation techniques and DDD techniques. Context mapping was the DDD technique most frequently used by authors to model microservices candidates as BCs in a context map [2]. The difference between the practice and theory of DDD is that context mapping usually involves some relational strategic patterns such as ACL, CS, and Shared-Kernel, among others, to define the communication between BCs development teams, while in practice, context mapping was the procedure mentioned by authors to only extract and represent BCs from legacy monolithic systems or business domains.

Event-storming [4] was a technique related to DDD, as mentioned in PS-01, to identify subdomains, where each subdomain was considered a microservice. Although the authors of PS-01 mentioned the work product obtained after event-storming execution (DDD subdomains), no details were mentioned about the procedure followed to perform event-storming. Due to the above lack of details about the Event-Storming process, it has become one of the most frequent techniques mentioned in DDD books and literature, but it is one with little use in industry contexts.

Regarding elicitation techniques, these were used together with UL. There are some strategies described in DDD literature to cultivate a UL, such as domain storytelling, knowledge crunching, and others. However, the authors of primary studies used interviews (mainly), brainstorming, focus groups, and questionnaires to extract the domain knowledge from the interaction with domain experts.

One important thing is that other activities were used to analyze the business domain and apply DDD principles. However, most of them were not described in detail or emphasized during microservices-based systems design with DDD. For example, in primary studies, PS-03, PS-04, PS10, PS-20, and PS-27, authors used domain modeling to analyze business problems. In PS-22 and PS-03, a monolithic system database was analyzed to identify key concepts for UL. In PS-10, an analysis based on the use case model and descriptions was performed to extract domain objects to conform aggregates, which were treated as the scope of microservices. Another example is described in PS-09, where authors performed a documentation review together with interviews with clients to familiarize themselves with the business domain terminology and cultivate a UL.

Based on the above examples, it is possible to notice that although the authors of primary studies emphasize techniques to complement domain analysis with DDD, other activities were used depending on the business problem and the type of development required in each microservices-based system.

(6) RQ-06: What challenges are mentioned by authors during the development of microservices-based systems? The authors mentioned 13 challenges when they used DDD in their development processes. These challenges are shown in Fig. 17.

Fig. 17. [Images not available. See PDF.]

Challenges faced with DDD in microservices-based systems development.

The challenges identified were classified into six categories based on the problems that the authors described in primary studies. As shown in Fig. 17, the authors of primary studies mention two main difficulties. The first one is the procedure that is not defined. It consists of the lack of a strict process to apply DDD techniques and patterns “correctly.” The decision of what DDD pattern should be used and how depends on the business domain and the comprehension of a software engineer about the context of the problem.

The second main challenge mentioned by authors of primary studies is related to the limitations mentioned by Evans [2]. When technical complexity predominates over the complexity of the business domain, DDD can complicate the solution. The authors mentioned this because they do not recommend using DDD for developments where the most significant complexity is technical.

Another challenge mentioned by the authors is related to developers who try to apply DDD in their microservices design. This challenge comes from an inherent complexity and cognitive load for DDD that can disorient the design decisions of some developers who have not faced industry business domains. For some authors of primary studies (PS-20 and PS-30), the use of experience and skill of developers is a crucial part of the DDD analysis and, therefore, a challenge for DDD practitioners.

The high coupling was mentioned in two primary studies. Authors of PS-09 and PS-33 reported having identified high coupling between their microservices, attributing this to using the BC pattern to delimit them. Although this challenge was overcome, the authors mentioned the necessity of research to analyze BC’s sizing benefits and consequences as a microservice representation. This research could also explore using other DDD patterns, such as Aggregate, as microservices candidates.

Another challenge mentioned by the authors was the lack of traceability in implementing each microservice based on a DDD domain model. This challenge appeared in the attempt to find some documented specifications of certain design decisions of the APIs exposed by microservices. Although each API had been designed with aggregate in a DDD domain model in the primary studies, this model was not enough to explain all the developers’ implementation decisions, according to the authors of the primary studies.

Lastly, the authors of PS-07 used DDD domain models and a database model for infrastructure layer design. They identified a scenario where both artifacts could be inconsistent due to the difficulties of representing some DDD patterns, such as domain service or domain event, in a relational model by keeping the consistent rules in the database or infrastructure layer of the microservices.

(7) RQ-7: What proposals exist for the development of microservices-based systems with DDD? Due to the incremental use of DDD in microservices-based systems development, some authors have proposed procedural guidelines to overcome the most frequent challenges of microservice architecture with the helplessness of DDD. These proposals are shown in Fig. 18, and they were classified according to the proposal type described by the authors of primary studies where they were extracted.

Fig. 18. [Images not available. See PDF.]

Proposals for microservices design with DDD.

As shown in Fig. 18, 21 proposals were identified and classified into five categories. These categories come from the denomination authors use to refer to their proposals. For example, the authors named their proposals “Approaches” in six primary studies. In five primary studies, authors named their proposals as “Methodologies” and so on. Based on Fig. 14, it is also possible to see that 80.95% of proposals were evaluated by authors. In comparison, 19.05% were not evaluated, postponing their evaluation to future works or delegating the evaluation for interested lectures.

Regarding approaches, the authors of the primary study PS-10 proposed using the Strangler Fig Pattern and DDD principles for migrations from monoliths to microservices. In PS-30 and PS-31, the authors proposed using architectural patterns such as clean architecture and hexagonal architecture, including DDD tactical patterns, for microservices design. PS-15, PS-18, and PS-32 authors proposed strategies for representing microservices architectures and some strategic patterns. These strategies involve modeling tools like UML Profiles, Metamodels, and others.

The methodological proposals were described as a sequence of activities or tasks that could enable the achievement of microservices with low coupling and high cohesion. In PS-14, authors proposed a methodology named MicroIoT for IoT microservices-based systems development using the strategic design of DDD. In primary studies, PS-8, PS-12, and PS-33, some methodologies were proposed together with other strategies and initiatives, such as SEMAT kernel and actor-driven decomposition, to overcome the challenges of domain analysis with DDD. A coding proposal was described in PS-05 in the form of a methodology. Authors of PS-05 proposed an approach named LEMMA (language ecosystem for modeling microservice architecture), which, together with a UML profile, could enable the automatic derivation code from technical under specific DDD domain models.

Regarding the process proposed by authors, two proposals were made by authors of primary studies PS-02 and PS-21. These processes used DDD combined with DevOps practices for refactoring in microservices-based systems. The authors of PS-22 proposed a process to develop a microservices-based system with strategic and tactical design by following all Software development life cycle (SDLC). Another process was proposed by authors of PS-28, which could be used to generate code for microservices-based systems development from general-purpose languages. In PS-28, an example of this proposal was described, where the authors transformed DDD domain models based on class diagrams into text, which was then translated into a specific programming language for implementing each microservice’s business domain layer.

Reference architectures share the same principle of using DDD patterns and other design patterns for microservices design. Some of the common design patterns proposed by authors to complement DDD in microservices design were CQRS (PS-07, PS-16), Mediator (PS-07, PS-16), Saga (PS-16), and Strangler Fig (PS-10, PS-16). In the case of reference architectures, the use of tactical patterns is commonly related to the mentioned design patterns of microservices instead of strategic patterns.

Lastly, only two primary study frameworks were proposed. One of these frameworks was proposed for microservice identification with strategic design through a custom procedure defined by the authors of PS-03. Another framework was proposed in PS-17, and its target was to design the infrastructure layer of microservices with aggregate to guarantee ACID transactions into each microservice.

Thematic Synthesis Results

As a result of the systematic literature review, a familiarization phase recommended by Braun and Clark [28] was performed. However, a new data extraction was conducted based on RQs and thematic synthesis guidelines [27]. This data collection enabled us to identify meaning patterns among the data. This first level resulted in a set of code concepts seen as building blocks of themes. A sum of 32 codes were identified from the evidence. These codes were transformed into 11 themes that isolate the idea behind a group of codes. In the end, five higher-order themes were identified through theme grouping. These relations between higher-order themes and themes are described in Table 6 of the Annexes section.

Based on the content of Table 6, it is possible to describe a particular story of collected data, as mentioned by Braun and Clark [28]. This high-level overview synthesized with thematic synthesis can be seen in Fig. 15 in the high-order themes model.

(1) Cross-stakeholders communication. According to Vlad Khononov [4], the central idea of DDD is the communication. Comprehending the domain problem is the key to an effective software system. The domain knowledge shared between domain experts and developers should be clear and consistent. With this similar purpose, authors of primary studies familiarized themselves with the domain experts’ jargon and used it to cultivate a UL free of technical details and ambiguous terms. This approach forms the basis of the theme “Ubiquitous Domain Language”, which consists of using UL as a business domain glossary to enrich the domain knowledge exchange between stakeholders.

However, the UL does not necessarily mean to use the business domain vocabulary for communication. If domain experts use an unclear vocabulary riddled with synonymous and ambiguous details, it is necessary to cultivate a language structure around the business domain to avoid ambiguous domain understanding. This necessity is why authors of primary studies PS-03, PS-07, PS-09, PS-10, PS-12, PS-20, and PS-27 selected a set of the critical business concepts required to conform to the UL. This distillation process of business domain vocabulary is the idea behind the “Domain Terminology Discovery” theme. After identifying this key business concept, the UL was used according to the principles proposed by Eric Evans [2]. This common language was mentioned only in industry systems developments during interaction with domain experts, where the authors emphasized the importance of a clear comprehension of the business domain that will be decomposed in microservices. For 20% of primary studies, UL is the key to DDD design. The terminology isolated by ULs represents the initial domain objects (Entities or value objects) used for microservices identification and modeling with DDD domain models.

(2) Microservice identification. Cultivating UL enables benefits related to effective communication, but another consequence of its usage is the identification of BCs. Each BC acts as a semantic boundary that delimits the meaning of the terms that conform to an UL. Through BCs, it is possible to decompose a business domain into semantic domain partitions that represent microservices. However, as shown in the above sections, using UL is not the only strategy authors use to decompose the domain into BCs and subdomains. The theme “Domain Decomposition” encompasses all the activities and strategies (described in the above sections) used by authors of primary studies for business domain partitioning into BCs, subdomains, or Aggregates that represent microservices. This semantic domain decomposition was one strategy used by authors for microservices identification.

Another strategy was identified using DDD analysis techniques to identify clusters of domain concepts. The authors performed event-storming to identify microservices candidates. This technique and the use of domain events reflect the “Domain Data Flow Analysis” theme, which involves the analysis of the closely related domain events that allowed authors to identify clusters treated as microservices. These two themes represent the two strategies used by authors of primary studies for microservices identification. One relates to using strategic patterns and techniques (context mapping) to split the business domain into consistent semantic microservices. The second theme concerns using tactical patterns and techniques (Event-storming) to cluster domain events from the business domain and conform to the cohesive microservices candidates.

(3) Microservices architecture design. After identifying microservices, the authors of the primary studies performed an architectural design of each microservice. This higher-order theme is where most differences exist between DDD literature and practice. Tactical design was mentioned by Evans [2], Vernon [5], and Vlad [4] as the DDD resource to specify how software should be built based on business logic. As described in section 5.1, DDD does not specify all the design aspects for microservices implementation. However, this is not the purpose of the authors of the primary study with DDD.

As shown in the above sections, all tactical design patterns were translated into using the DDD domain model to design the business domain layer for each microservice identified with strategic design. The domain layer is a crucial part of the architecture of the microservices-based systems developed by authors, which is why the theme “Domain Model-Based Microservices Design” was defined. However, some other technical details were not specified with DDD artifacts.

Mainly in industry systems development, challenges related to the design specification of microservices were mentioned. This lack of technical specification for microservices was why other design patterns such as CQRS, Saga, Strangler Fig, and others were used together with standardized diagrams to describe details related to the implementation of microservices. These design resources used to refine the preliminary design obtained with DDD were defined as the “Detailed Microservices Design” theme.

This complement of DDD does not mean that the specification with the DDD domain model did not provide value to the design of microservices. On the contrary, domain knowledge in the form of a domain model acts as the basis for all the architecture specifications of microservices. In addition, using detailed design artifacts and patterns was not the only way that the authors of primary studies refined DDD design. In the answers to RQ4, we notice another design resource to refine the design obtained with DDD for each microservice. This is the use of technologies mentioned in primary studies PS-05 and PS-09. This action to complement the design of microservices was defined as the “Design Support Technologies” theme.

(4) Challenges. In answer to RQ6, challenges mentioned by authors of primary studies were extracted. As a result of thematic analysis, these challenges were classified into two themes that represent the two main difficulties faced by developers during microservices design with DDD. One of the challenges is related to the application of DDD. This theme is named “Inherent Complexity of Domain-Driven Design”, and it is related to the lack of guidelines, checkpoints, and a strict path to know if a developer is applying DDD correctly. In addition, some authors mentioned the necessity of the experience and skill of DDD practitioners to map each business domain concept to a specific DDD pattern during domain modeling. Even when there are rules for each DDD pattern, at the beginning of domain analysis, there is no clear idea about the properties of domain objects that could be used in microservices modeling.

Another challenge was defined as “Domain Model Implementation Obstacles”, which comes from the problems faced by authors who tried to implement the DDD domain models. Some authors have made some proposals; however, there are no rules, guidelines, or strict specific ways to generate code from these DDD artifacts. We have some proposals and examples of DDD implementation in books, such as “Implementing Domain-Driven Design” by Vernon [5] or “Learning Domain-Driven Design” by Khononov [4]. However, there are not enough details about the implementation of DDD in industry contexts with a set of requirements of infrastructure, hardware, and other technologies commonly used in the last decade. This challenge was emphasized in the primary study PS-05 due to the lack of technical details in DDD domain models and specific guidelines to implement the DDD patterns (tactical patterns mainly). For this reason, the authors of PS-05 proposed a framework to generate code from a UML profile used with DDD principles.

(5) Benefits. Just as the authors of primary studies have reported challenges in the use of DDD for microservices-based systems development, some authors mentioned the benefits obtained from the execution of some of DDD techniques and the use of its patterns. Some authors of primary studies mentioned benefits related to development complexity. In PS-04, PS-05, and PS-30, authors described the business domain complexity isolated into some DDD patterns such as BCs, aggregates, or subdomains. This isolation enabled them to tackle the most significant complexity of their microservices-based projects, the business domain logic. At the same time, this design based on domain objects resulted in a microservices-based system closely related to the business domain, fulfilling Conway’s law. This close relationship between system and business domain was mentioned by authors of primary studies PS-02, PS-08, PS-10, PS-11, PS-12, and PS-27, and this benefit contributes to the increase in software effectiveness. These benefits were grouped into the theme “Business-Technical Alignment Advantages”.

Furthermore, other primary study authors mentioned benefits during the microservices size definition. Based on the decomposition process followed by authors, each microservice could sometimes be represented as a BC or an aggregate. According to the authors of primary studies PS-05, PS-10, PS-11, PS-16, PS-18, PS-31, PS-07, PS-20, PS-21, and PS-26, with DDD, it is possible to establish the microservice scope based on business responsibilities. This approach means that each microservice is related to an activity area of a domain, with a set of domain objects closely related to each other with only one specific meaning. This decomposition proposed by DDD contributes to modifiability. This is because when the business changes arrive if one business activity area (BC) changes, only one microservice should be changed due to its business scope. In some primary studies such as PS-11, PS-12, PS-22, and PS-29, authors emphasized the loose coupling and small size of microservices designed as BCs, where each microservice reflects the business organization through independent microservices with a single business responsibility.

All these high-order themes with the related themes are shown in Fig. 19, where relationships between some themes represent the impact of different ideas across various high-order themes. As shown in Fig. 19, there are relationships between cross-stakeholders communication, microservices identification, and microservices architecture design. This relationship can be interpreted as the use of DDD for domain analysis to increase the comprehensiveness of the problem in terms of domain experts. This knowledge is the basis for microservices identification, which isolates each UL into a semantic boundary. Some benefits come from this strategic design with BC and UL. Finally, the relationships shown in Fig. 19 highlight some challenges that arise from domain modeling with the DDD domain model, explaining why it is not recommended to use DDD when the most significant complexity of a software project is technical.

Fig. 19. [Images not available. See PDF.]

Thematic map of domain-driven microservices design.

DISCUSSION

In this study, we successfully answered all the research questions by employing the research method conduction. Our efforts involved collecting and synthesizing a wealth of knowledge on the practical use of domain-driven design (DDD) in developing microservices-based systems.

Analyzing the demographic results of the study yielded interesting findings, particularly an increased interest in the adoption of DDD in microservices architecture (MSA). This surge in primary studies may be attributed to the impact of the COVID-19 pandemic around 2020. Section 5 of this study presented a comprehensive set of results, allowing us to identify various applications of DDD patterns and techniques within the context of MSA.

It is worth noting that a gap exists between theoretical understanding and practical implementation of certain patterns, such as Subdomain or BC. Consequently, through this research, we have provided evidence-based knowledge on these patterns and their application. Our findings complement the grounded theory study published by Singjai et al. [18] and the systematic review conducted by Schmidt et al. [19], offering valuable insights into the practical use of DDD in microservices system design.

The utilization of domain-driven design (DDD) has emerged as a vital component in the domain analysis phase of microservices-based systems development within the industry. Strategic design, in particular, plays a crucial role in establishing a shared understanding among stakeholders, enabling authors to express ideas unambiguously. Conversely, developers have primarily utilized tactical design to tackle controlled domain problems and serve specific purposes. Additionally, existing literature indicates that DDD has been employed to decompose business domains into microservices candidates in the analysis process. However, it is important to note that the BC pattern is not the only one utilized or emphasized in the literature. Using UL for stakeholder interaction is a common practice in complex domains where developers may not be familiar with the domain. On the other hand, applying Tactical design in industrial projects has been less frequent. Thus, certain DDD patterns, such as domain event, event-sourcing, and domain services, remain underutilized in real-world contexts.

DDD Usage in MSA

Based on the findings presented in Section 5, we can highlight the reasons why authors have leveraged domain-driven design (DDD) principles in their microservices-based projects. The primary DDD principle mentioned by the authors revolves around strategic and tactical patterns. These patterns are utilized to create a domain-oriented preliminary design based on a thorough understanding of the business domain or as the core implementation structure in other cases. Additionally, we identified the usage of DDD through techniques related to DDD patterns, such as context mapping, DDD domain modeling, and event-storming. However, these techniques were observed with less frequency compared to patterns.

The classification of systems designed with DDD and MSA has shed light on a notable characteristic of DDD implementation. It reveals that strategic and tactical design patterns vary based on the type of system developed. Among the 94 microservices-based systems collected, 44 correspond to industry systems (46.81%), while the remaining 50 are example systems (53.19%). Within the industry systems, 72.73% employed strategic patterns, whereas tactical patterns were predominantly used in 70% of the example systems. These findings indicate that strategic design is more prevalent in industry projects, while authors who develop example microservices-based systems tend to rely on tactical design. The three applications of domain-driven design (DDD) illustrated in the Thematic map of Section 5.2 further contribute to understanding the usage of DDD in microservices-based systems development, particularly in industry settings.

One significant use of DDD in industry systems is establishing and cultivating a concise and shared domain language. This language facilitates effective communication and comprehension of the domain problem during discussions between developers and domain experts. Conversely, this use of DDD was not explicitly mentioned in example systems, possibly due to the lower complexity and greater familiarity with the controlled or restricted business domains of these systems.

Another prevalent application of DDD is in identifying microservices, which serves as a primary objective in microservices design. This use of DDD was recognized in both industry and example systems, with a focus on patterns such as subdomain and BC. Additionally, patterns like context mapping and event-Storming were occasionally employed to support this identification process. Although most primary study authors frequently mentioned BC, it emerged as the DDD pattern with the highest variability in its usage.

In the context of DDD, each microservice can be equated to a BC, with each BC representing the boundary of a specific model (UL). However, it is important to note that while some primary studies adhere to the DDD literature by applying BC as intended, others utilize BC merely as a semantic boundary to group diverse design elements such as use cases, classes, functional requirements, CRUD operations, or other criteria that authors did not explicitly mention.

Additionally, the architecture of each microservice, when employing tactical design, was predominantly observed in example systems. As showcased in the Thematic map, this tactical design approach within the DDD domain model can complement other design artifacts based on established standards like UML and SysML.

Benefits of Utilizing DDD in MSA

Most of the benefits highlighted by the authors have been discussed in Section 5.2; however, it is evident that the utilization of DDD has provided authors with criteria for defining the scope of microservices. The modularity inherent in MSA and the associated benefits derived from this property stand out as key characteristics of this architectural style. However, numerous papers have acknowledged microservices decomposition as a significant challenge and a critical aspect of MSA [9, 11]. With DDD, each microservice represents a semantic boundary within the business domain. The decomposition driven by DDD aligns with Conway’s law, aiming to achieve effective software organization. It is crucial to note that the decomposition process is not limited to using BC, as primary study authors have reported utilizing various DDD patterns, such as subdomain or aggregate, to define appropriate microservice scopes. However, BC still serves as a primary tool for decomposition.

The benefits highlighted by authors regarding the use of DDD in the context of MSA can be better understood by examining three distinct characteristics:

1. Clear responsibilities of microservices: Authors of primary studies have emphasized that DDD enables the creation of microservices with well-defined responsibilities that align with specific activity areas or subdomains within the business.

2. Alignment with business logic: DDD allows authors to align their microservices-based systems closely with the business logic. This alignment allows a deeper understanding of the system by closely mapping the business domain to the microservices architecture. Consequently, when changes in the business domain occur, the system becomes more flexible and adaptable, as modifications can be made more rapidly and seamlessly.

3. Control of business complexity: DDD provides a means to manage the complexity inherent in the business domain. This management is achieved by applying the divide and conquer principle, wherein complex business domains are broken down into manageable subdomains. The encapsulation of business domain complexity within a DDD domain model forms the foundation for the detailed design of the system.

Limitations and Opportunity Areas

Despite the numerous benefits mentioned by authors in primary studies regarding the use of DDD for microservices-based systems development, there are also challenges associated with applying DDD principles to microservices design. These challenges were discussed in detail in Section 5, with some authors highlighting opportunities for future research based on these difficulties.

It is important to note that most primary study authors did not provide specific details about the code implementation resulting from a DDD design. However, authors of primary studies PS-11, PS-20, and PS-04 have mentioned the possibility of generating code from DDD domain models for microservices implementation. While there are books available, such as “Implementing Domain-Driven Design” by Vernon [5] and “Learning Domain-Driven Design” by Khononov [4], there is a lack of clear guidelines on how to implement a DDD domain model in real-world projects and the potential impact of such code generation on code artifacts.

Another area of opportunity is related to a limitation mentioned by authors regarding the inherent complexity of DDD. Primary studies PS-30 and PS-34 specifically address this complexity challenge. Authors have proposed steps and resources to reduce the complexity of developing microservices-based systems using DDD. The opportunity lies in validating and evaluating these proposals, as their effectiveness can significantly impact developers who face challenges similar to those of the authors of these proposals.

THREATS TO VALIDITY AND LIMITATIONS

In the literature reviews, Kitchenham and other authors [23]– [27] emphasized the importance of reliability. This aspect was carefully considered throughout the research process, from manual search to data synthesis using Cruzes and Dyba’s proposal. We implemented a series of mitigation measures to minimize potential biases at various stages of the research.

To ensure the selection of relevant papers was unbiased, we utilized a manual search approach and established inclusion and exclusion criteria based on the quasi-gold standard. These criteria helped us avoid solely relying on one search engine’s studies. Once we identified primary studies, we further augmented our research by employing a snowballing technique. This process helped to minimize the possibility of overlooking any relevant studies.

Once the selection process was complete, the chosen primary studies underwent a rigorous evaluation by the authors of this study to ensure their relevance to at least one RQ. Also, the authors continuously reviewed and revised their work during the data extraction process to maintain accuracy. Review questions were developed and regularly evaluated to avoid omissions and confirm that no crucial data had been missed. The same meticulous approach was applied when defining themes and subthemes, with each code being meticulously linked to specific text segments and the themes closely tied to these codes. In the same way, the names assigned to the codes, themes, and higher-order themes were determined through collaborative revisions among the authors of this study. The relationships between themes and the clustering of codes were thoroughly discussed, and a consensus was reached.

To enhance the quality of the analysis, we discussed the evidence and findings obtained through the research process among the authors of this secondary study. This collaborative effort allowed for a comprehensive review and refinement of our interpretation of the data extraction process and synthesis.

In line with Cruzes and Dyba’s recommendation for ensuring transferability, we have made all our analysis evidence available on Zenodo. This platform serves as a repository for the analysis artifacts that underpin the conclusions and content of this work. By uploading these artifacts, we aim to enhance transparency and provide a comprehensive basis for future research and validation.

CONCLUSIONS

In this study, we adopted the systematic literature review method proposed by Kitchenham [23] to examine the utilization of DDD in developing a microservices-based system. We formulated seven research questions (RQs) to guide our research process and ensure focused research. Our selection process involved both manual and automatic searches to identify relevant studies. Through this process, we identified 31 primary studies. We also employed snowballing techniques to enhance our selection, which led us to four additional studies. We then conducted a preliminary synthesis to familiarize ourselves with the primary studies and address the RQs, mainly focusing on the application of DDD in the development of microservices-based systems. To gather the necessary data, we performed an extraction process. To provide a comprehensive analysis, we further conducted a thematic synthesis utilizing the method proposed by Cruzes and Dyba. To complement this approach, we also incorporated recommendations from the Braun and Clark proposal, ensuring a robust analysis of the collected data.

Throughout our analysis, we have identified specific details regarding the application of DDD that contribute to enhancing effective knowledge sharing between developers and domain experts. These details primarily revolve around the integration of UL with DDD and the utilization of various elicitation techniques. Interestingly, these aspects have not been extensively addressed in related studies, thereby providing fresh insights into the broader scope of DDD beyond its traditional utilization for system decomposition.

Among the different uses we discovered, the most frequently reported one involves decomposing a business domain or legacy system into microservices. However, our analysis captured new and pertinent details about using strategic patterns to define the business scope of microservices, as well as variations and adaptations.

Another significant use of DDD that we identified is its application in the design and architecture of individual microservices using a DDD domain model. This approach is often enhanced by incorporating other design artifacts based on widely adopted standards like UML and SysML. The approach can be extended to integrate DDD throughout the entire microservices design process, starting from the initial business domain analysis. This continued utilization of DDD plays a vital role in the identification and subsequent design of microservices, leveraging the valuable business knowledge acquired through DDD and other complementary strategies.

Most authors in the primary studies highlighted the successful implementation of microservices, explicitly noting the absence of coupling issues between microservices. Some authors went so far as to underscore DDD’s potential for achieving an optimal scope of microservices based on business capabilities. While the remaining authors did not mention any problems in their DDD-driven microservices systems, they did not specifically address certain characteristic aspects of DDD within the context of MSA.

Despite the overall positive outcomes reported, some challenges persist in the practical application of DDD. These challenges primarily stem from the perceived complexity of implementing DDD, which can be particularly daunting for developers without prior experience analyzing and designing intricate business domains. Additionally, there is an opportunity for future work in refining the implementation of DDD artifacts, such as the domain model, to further enhance its effectiveness and efficiency in microservices development.

Based on the findings of this research, it is evident that developers working on industry systems often perceive significant value in strategic design, considering tactical design only as a preliminary stage that requires further refinement with the utilization of additional design patterns such as CQRS, Saga, and others. Conversely, developers working on example systems tend to utilize tactical design more frequently throughout their projects.

Furthermore, the primary motivation for employing DDD, as highlighted in the results of this study, continues to be the identification and definition of microservices. Many authors from the studies included in this research tend to align the responsibilities of their microservices with the activity areas that form part of the business domain. Here, activity areas are understood as groups of individuals performing specific tasks that collectively contribute to the main service of the business domain [4].

This study identified significant details concerning the application of DDD in MSA. These findings not only provide valuable insights for developers seeking to bridge the gap between DDD principles and practical implementation but also have the potential to inspire future research in the areas of DDD and MSA, building upon the knowledge generated from this study.

Finally, we envision future work focused on delving into the creation of DDD patterns that allow the development of code that effectively represents the underlying business logic, with minimal dependencies on specific programming languages based on object-oriented programming.

FUNDING

This work was supported by ongoing institutional funding. No additional grants to carry out or direct this particular research were obtained.

CONFLICT OF INTEREST

The authors of this work declare that they have no conflicts of interest.

1

https://scholar.google.com/

2

https://www.maxqda.com/

3

https://grpc.io/

Publisher’s Note.

Pleiades Publishing remains neutral with regard to jurisdictional claims in published maps and institutional affiliations.

AI tools may have been used in the translation or editing of this article.

REFERENCES

1 Sangabriel-Alarcón, J., Ocharán-Hernández, J.O., Cortés-Verdín, K., and Limón, X., Domain-driven design for microservices architecture systems development: A systematic mapping study, Proc. 11th Int. Conf. in Software Engineering Research and Innovation (CONISOFT), Leon, 2023, pp. 25–34.

2 Evans, E. Domain-Driven Design: Tackling Complexity in the Heart of Software; 2004; 18.0139.02

3 Evans, E. Domain-Driven Design Reference: Definitions and Pattern Summaries; 2014; 1325.05009

4 Khononov, V.; Lerman, J. Learning Domain-Driven Design: Aligning Software Architecture and Business Strategy; 2021; 0988.68684

5 Vernon, V. Implementing Domain-Driven Design; 2013; 1015.90010

6 Lewis, J. and Fowler, M., Microservices: A definition of this new architectural term, 2014. https://martinfowler.com/articles/microservices.html.

7 Newman, S. Building Microservices: Designing Fine-Grained Systems; 2021; 1396.37060

8 Velepucha, V. and Flores, P., Monoliths to microservices-migration problems and challenges: A SMS, Proc. 2nd Int. Conf. on Information Systems and Software Technologies, ICI2ST 2021, Quito, 2021, pp. 135–142. https://doi.org/10.1109/ICI2ST51859.2021.00027

9 Liu, G., Huang, B., Liang, Z., Qin, M., Zhou, H., and Li, Z., Microservices: Architecture, container, and challenges, Proc. Companion of the 20th IEEE Int. Conference on Software Quality, Reliability, and Security, QRS-C 2020, Macau, Dec. 2020, pp. 629–635. https://doi.org/10.1109/QRS-C51114.2020.00107

10 Mubashir, R., Ahmed, J., Khakwani, F., and Rana, T., Microservices architecture: Challenges and proposed conceptual design, Proc. Int. Conf. on Communication Technologies (ComTech), Rawalpindi, 2019.

11 Salii, S., Ajdari, J., and Zenuni, X., Migrating to a microservice architecture: Benefits and challenges, Proc. 46th MIPRO ICT and Electronics Convention (MIPRO), Opatija, 2023.

12 Valdivia, J.A.; Lora-González, A.; Limón, X.; Cortes-Verdin, K.; Ocharán-Hernández, J.O. Patterns related to microservice architecture: A multivocal literature review. Program. Comput. Software; 2020; 46, pp. 594-608. [DOI: https://dx.doi.org/10.1134/S0361768820080253]

13 Niño-Martínez, V.M.; Ocharán-Hernández, J.O.; Limón, X.; Pérez-Arriaga, J.C. A microservice deployment guide. Program. Comput. Software; 2022; 48, pp. 632-645. [DOI: https://dx.doi.org/10.1134/S0361768822080151]

14 Rademacher, F.; Sorgalla, J.; Sachweh, S. Challenges of domain-driven microservice design: A model-driven perspective. IEEE Software; 2018; 35, pp. 36-43. [DOI: https://dx.doi.org/10.1109/MS.2018.2141028]

15 Tello-Rodríguez, M.; Ocharán-Hernández, J.O.; Pérez-Arriaga, J.C.; Limón, X.; Sánchez-García, Á.J. A design guide for usable web APIs. Program. Comput. Software; 2020; 46, pp. 584-593. [DOI: https://dx.doi.org/10.1134/S0361768820080241] 1410.65356

16 Jin, B.; Sahni, S.; Shevat, A. Designing Web APIs: Building APIs That Developers Love; 2018;

17 Fritzsch, J., Bogner, J., Wagner, S., and Zimmermann, A., Microservices migration in industry: Intentions, strategies, and challenges, Proc. IEEE Int. Conf. on Software Maintenance and Evolution, ICSME 2019, Cleveland, OH, Sep. 2019, pp. 481–490. https://doi.org/10.1109/ICSME.2019.00081

18 Singjai, A., Zdun, U., and Zimmermann, O., Practitioner views on the interrelation of microservice APIs and domain-driven design: A grey literature study based on grounded theory, in Proc. 18th IEEE Int. Conf. on Software Architecture, ICSA 2021, IEEE,, Mar. 2021, pp. 25–35. https://doi.org/10.1109/ICSA51549.2021.00011

19 Schmidt, R.A. and Thiry, M., Microservices identification strategies: A review focused on model-driven engineering and domain driven design approaches, Proc. 15th IEEE Iberian Conf. on Information Systems and Technologies (CISTI), Seville, 2020. https://ieeexplore-ieee-org.ezproxy.uv.mx/document/9141150/. Accessed November 13, 2022.

20 Macias, A., Navarro, E., Cuesta, C., and Zdun, U., Architecting digital twins using a domain-driven design-based approach, Proc. Int. Conf. on Software Architecture (ICSA), L’Aquila, 2023, no. 62, pp. 183–209. https://doi.org/10.13039/501100011033

21 Praschl, C., Bauernfeind, S., Leitner, C., and Zwettler, G.A., Domain-driven design as model contract in full-stack development, in Proc. Int. Conf. on Electrical, Computer, Communications and Mechatronics Engineering, ICECCME 2023, IEEE, 2023. https://doi.org/10.1109/ICECCME57830.2023.10252654

22 Rademacher, F.; Sachweh, S.; Zündorf, A. Including Subseries Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics); 2018; [DOI: https://dx.doi.org/10.1007/978-3-319-74781-1_17/COVER] 0894.47051

23 Kitchenham, B.A.; Budgen, D.; Brereton, P. Evidence-Based Software Engineering and Systematic Reviews; 2015; [DOI: https://dx.doi.org/10.1201/b19467] 0751.68011

24 Zhang, H.; Babar, M.A.; Tell, P. Identifying relevant studies in software engineering. Inf. Software Technol.; 2011; 53, pp. 625-637. [DOI: https://dx.doi.org/10.1016/j.infsof.2010.12.010] 07640631

25 Wohlin, C., Guidelines for snowballing in systematic literature studies and a replication in software engineering, in Proc. 18th Int. Conf. on Evaluation and Assessment in Software Engineering – EASE’14, New York: ACM Press, 2014, pp. 1–10. https://doi.org/10.1145/2601248.2601268

26 Popay, J., et al., Guidance on the Conduct of Narrative Synthesis in Systematic Reviews. A Product from the ESRC Methods Programme.Version 1, Lancaster Univ., 2006. https://doi.org/10.13140/2.1.1018.4643

27 Cruzes, D.S. and Dybá, T., Recommended steps for thematic synthesis in software engineering, in Proc. Int. Symp. on Empirical Software Engineering and Measurement, IEEE Computer Soc., 2011, pp. 275–284. https://doi.org/10.1109/esem.2011.36

28 Clarke, V. and Braun, V., Thematic Analysis: A Practical Guide, London: SAGE, 2021. https://uk.sagepub.com/en-gb/eur/thematic-analysis/book248481#description. Accessed Oct. 30, 2023.

29 Moher, D.; Liberati, A.; Tetzlaff, J.; Altman, D.G. Preferred reporting items for systematic reviews and meta-analyses: the PRISMA statement. Int. J. Surg.; 2010; 8, pp. 336-341. [DOI: https://dx.doi.org/10.1016/j.ijsu.2010.02.007] 0448.47043

30 Sangabriel-Alarcón, J., Ocharán-Hernández, J.O., Limón, X., and Cortés-Verdín, K., Domain-driven design in microservices-based systems development: a systematic literature review and thematic analysis. https://zenodo.org/records/13294975.