Evaluating the Efficacy of Domain Driven Design for Microservices Decomposition

(1)

Following Domain Driven Design principles for Microservices decomposition: is it enough?

Hassan Farsi, Driss Allaki, Abdeslam En-nouaary, Mohamed Dahchour Institut National des Postes et T´el´ecommunications, Rabat, Morocco

{farsi.hassan, d.allaki, abdeslam, dahchour}@inpt.ac.ma

Abstract—Building software using a microservice architecture is a means that gives more options to scale up applications, deploy them independently and limit their ”blast radius” of failure. Microservices tend to solve the complexity and the increasing development problems by applying the functional decomposition principle. This main feature can become a point of weakness in the absence of a fully credible splitting mechanism. One of the main adopted approaches to design services and deal with the boundary identification concern is the Domain Driven Design (DDD). In this paper, we aim to study the efficiency of this approach. We intend to give software architects a full understanding of its capabilities and main limits to be aware of the potential resulting anti-patterns. To this end, we use graph theory to experiment and analyze a reference example, implementing many microservices good practices and patterns. The obtained results show whether if we can rely only on the DDD principles to decompose microservices, or not.

Index Terms—microservice architecture, decomposition patterns, domain driven design, anti-patterns detection, graph algorithms

I. INTRODUCTION

Microservices are an architectural and organizational approach to software development where applications are com- posed of independent services that communicate over well- defined application programming interfaces (APIs). This approach is designed to speed up deployment cycles, foster innovation and ownership and improve the maintainability and scalability of software applications.

Decomposing applications into microservices is one of the most difficult and crucial parts when designing and implementing such applications. Wrongly splitting a microservices-based architecture can lead to very dangerous disasters.

A recommended approach to decompose and identify boundaries between microservices is applying some of the Domain Driven Design (DDD) concepts. Evans [1] describes the DDD as an approach to develop complex software while focusing on the business regardless of the technology that is being used. It is a way to see the software from a top vision, from a domain perspective.

In this paper, we aim to answer the following research question:Is it sufficient to use the DDD principles to efficiently decompose microservices? More accurately, will a DDD-based microservices decomposition prevent from having architectural anti-patterns?

In fact, the efficiency of a DDD-based microservice decomposition can be evaluated with the absence of the architectural

anti-patterns. For instance, a chattiness of a service, the overload domain objectsor thedistributed monoliths[16], [17]

are some anti-patterns to avoid in a microservice architecture.

This paper is organized as follows: Section II presents best practices and patterns to decompose microservices. Section III introduces our graph-based approach to assess a DDD- based microservices decomposition. Section IV motivates the chosen case study, then presents and discusses the obtained results. Section V proposes related work. And the final section concludes and announces our future work.

II. BACKGROUND: MICROSERVICE BOUNDARIES IDENTIFICATION

Microservice architectures are based on functional decomposition of services. The principle of decomposition did not find its origin with microservices. It is the result of several technological leaps started with distributed computing, service-oriented architecture [2] and now reactive systems.

A service is a standalone entity that offers a useful function- ality. A lot of grey areas exist in such a concept revealing many unanswered questions: What is the size of a typical service?

What are its borders? And how can we define a service?

Actually, every microservice architecture must fulfill a set of criteria in order to have a good decomposition. The architecture must be stable, and services must conform two main principles, namelySingle Responsibility Principle (SRP) which means that a service must have only one reason to exist and Common Closure Principle (CCP) which means entities that change together should be packaged together [3]. Services must also be loosely coupled. The service provides an API that hides its implementation. Changes in a service must not affect the client. Services must be small to be handled by a team of six to ten people that work in an autonomous way. Projecting all this information on reality gives birth to two major recommend strategies to define and decompose microservices, decomposing bybusiness capabilitypattern and decomposing bysub-domain pattern.

A. Decomposing by business capability pattern

As the name indicates, business capability is based on the ability of achieving a goal or generate a value. A business is a set of multiple capabilities in a way that their collaboration help achieve the overall goal. Business capabilities are different from a business to another. Even in the same sector, enterprises could define them in different ways. The business

(2)

capabilities are extracted while analyzing the organization’s purpose, structure, business processes and the business work- flow. The results must be taken from a business-perspective rather than a technical one and it needs a fuller understanding of the way things are being done.

From a microservice perspective, the business capability pattern defines a service as a capability or a group of related capabilities. We can then map business capabilities to services.

The mapping result generates a set of service entities, each one is clustered among a purpose, and work to offer a value in a bigger system.

Decomposing by business capability pattern has a lot of advantages. It first tends to create a stable architecture. More- over, studying the relationship between software design and development teams based on Conway’s law [4] leads to have cross-functional teams, autonomous, and organized around delivering business value rather than technical features.

B. Decomposing by sub-domain pattern

The other approach to decompose microservices is based on the Domain Driven Design principle. As already mentioned, the DDD is based on an object-oriented domain model. A domain is a sphere of knowledge, a representation that distills knowledge and assumptions about that domain. Concentrating on the domain means giving the interest to the business we are trying to solve, by focusing on models. A model is an abstraction of a system representing the selected aspects of that specific domain.

DDD proposes two useful concepts when decomposing microservices: sub-domains andbounded contexts. DDD avoids the problems generated by the traditional modeling with the definition of multiple domain models for each sub-domain. A domain is a constitution of multiple sub-domains. They are identified the same way the business capabilities are. In DDD, within a domain, boundaries that appear within a domain model are called bounded context. Bounded contexts can be isolated or can interact each other. On the other hand, to make sub-domains communicating each other, we can use patterns, namely Open Host ServiceandPublished Language[1].

The implementation of the DDD concepts and principles when decomposing microservices seems to be well-aligned.

If we have a full understanding of our business, the mapping operation of sub-domains to services becomes much easier.

Moreover, the resulting microservice architecture will be stable, cohesive and loosely coupled which make it more trustable for production. However, is it sufficient to rely only on such strategy to specify the microservices boundaries? This is the main question we will answer in what follows.

III. THE PROPOSED APPROACH

In this section, we introduce the followed approach to answer our research question. The main idea is to transform a microservices-based architecture into a graph to extract metrics and key performance indicators (KPIs). To gain insight into the structure of this architecture. And then, try to get conclusions on the microservices decomposition efficiency.

A. Microservices and graphs: a perfect matching

At first glance, microservices and graphs seem to fit well together. Microservices roughly refer to a set of services connected with each other. In turn, graphs represent a set of vertices (or nodes) connected using edges (or links). Translat- ing microservice architectures to graphs means representing services as vertices and connections as edges. Thus, graphs could be a meaningful description and visualization for microservices. In their work, [5] has already demonstrated, via a case study, the efficiency of using graph theory to explore the microservice architecture and get useful information.

B. Predictive analysis and graph theory

Graph theory is used to study the graph we created. This study can be done using two different graphs’ sub-disciplines.

The first one isgraph analytics. It is an action performed on a graph in order to have a look at how the data is connected using an appropriate approach or tool. For this purpose, we usually rely on data visualization as a technique that allows getting the first type of insights and detecting patterns. The second graphs’ sub-discipline is graph algorithms. They are a set of programmable instructions or set of rules that uses mathematical properties and run across the network to give a further type of insights that can help explore, classify and interpret actions on a graph. According to [6], graph algorithms use the graph properties, nodes and relationships to infer the dynamics and the organization of a system to let scientists interpret and act on uncovering hidden information.

C. Graph algorithms

In a graph, the more data is connected, the more it is necessary to understand its relationships and interdependencies. This objective can be reached using graph algorithms. [6] describes them as tools to perform graph analytics. Their mathematical calculations are based on formal relationships that makes them very useful for analyzing connected data.

There are mainly five big categories of graph algorithms.

Each one gathers a set of algorithms with a common purpose but with different execution details. In what follows, we present the categories we used to analyze the graph representing our microservice architecture.

• Centrality:is one of the traditional graph algorithms that allow finding the most valuable and influential nodes in the network. In fact, there is a great deal of ways to determine a node’s importance. This could be based on the number of connections a node has, the number of the other nodes they can reach it, and so on. The centrality category provides several algorithms such as: Degree, Eigenvector, Page Rank, Betweenness and Closeness[6], [7]. Table 1 illustrates the role of each algorithm we used and its projection on a microservice architecture.

• Community Detection:is used when we are interested in finding clusters or partitions in the graph by detecting entities that overlap with each other. Community detection provides a lot of algorithms such as:Louvain, Modularity

(3)

Optimization, Label Propagation, Connected Component, Triangles Count, Local Clustering Coefficient and SLLPA.

Motivated by the logic behind each algorithm and its interpretation from a microservice perspective, we present in table 2 the algorithms we used in this work.

The three other categories of graph algorithms, that are not used in this work, are the Path finding and Search, the Heuristic Link Prediction and the Similarity. We have excluded these algorithms because they do not provide useful information for the analysis we performed.

TABLE I

CENTRALITY ALGORITHMS ON MICROSERVICE ARCHITECTURE

Algorithm Role MS Projection

Degree Number of relationships Number of calls Closeness Efficiently spread of in-

formation

key traffic services Betweenness Bridges detection Adapter and relational ser-

vices PageRank /

Eigenvector

Transitivity of a node Importance of a service

TABLE II

COMMUNITY DETECTION ALGORITHMS ON MICROSERVICE ARCHITECTURE

Algorithm Role MS Projection

Local Clustering Coefficient

Probability of knowing others

Chattiness of a service

Triangle Count

number of triangles a node participates in

Chattiness of a service Louvain /

Modularity Optimisation

Categorize groups of nodes

Communities of services

D. The followed Process

Taking into consideration all what was presented above, we present the followed process to assess the DDD-based microservices decomposition. The process, depicted in Figure1, shows the following steps:

Step 1:Choosing an experimental application. To add more reliability to our research, it is important to choose a well- constructed application for doing the necessary experimentations.

Step 2:Formalizing the microservices-based architecture. It is about translating a microservice architecture into a formal graphical graph-based representation.

Step 3: Applying graph science on microservice architecture. Run some graph algorithms to extract metrics and KPIs from the microservice architecture.

Step 4:Predicting and getting insights. Create visualization charts and figures in order to analyze the extracted data and get insights about the concerned architecture.

Step 5:Reacting according to the obtained results. Depend- ing on these results, we will be able to conclude if the DDD- based microservices decomposition is free of anti-patterns or not. If it is not the case, we can suggest a better architectural proposition.

Step 6: Comparing and concluding. Rerun steps 3 and 4 on the new architecture, then compare the new results and conclude.

DDD Experimental

Example

Application Graph Construction

Run Graph Analysis

?

Conclusion New Architecture

Proposition

1 2

3

4

Non Anti-pattern

5-a

Anti-pattern Detection 5-b 6-b

7-b

8-b

Predict and Get Insights

Fig. 1. The followed process to assess the DDD-based approach.

IV. OBTAINED RESULTS AND DISCUSSION In this section, we present the major contribution of the paper. We will first motivate the chosen case study to apply our experimentations. Then, we will transform its microservice architecture to a graph. After applying some graph algorithms, we will present the main obtained results, discuss them and take on this basis some architecting decisions. At the end, we will conclude with an overall synthesis and discussion.

A. The case study

The need to apply our experimentations on a trustworthy and reliable case study, pushed us to make wise choices about the microservices project we will work on. As criteria to respect, the chosen project has to mandatory follow the DDD’s concepts and principles when decomposing microservices, since we are trying to verify a hypothesis about that. The respect of other patterns and good practices concerning other architectural aspects is a nice to have. In addition to that, we decided to work on a project with a small to medium size in terms of the microservices number composing the application.

The reason behind this choice is to minimize the complexity of the chosen example for purely illustrative purposes.

After conducting a meticulous research on available open source microservices projects, we chose to perform on Chris Richardson’s book [8] illustrative example, the Food To GO (FTGO) microservice application [9]. FTGO is the reference application used as an illustrative example to explain many microservices related concepts and patterns such as: the importance of adopting microservices, decomposing them, different ways of communication, managing transactions, designing business logic, using external APIs in addition to testing, securing and deploying microservices. Figure 2 illustrates the initial FTGO architecture with some of its microservices.

The FTGO application uses in its decomposition strategy the sub-domain approach, which is the most important point we are looking for. Furthermore, FTGO’s services use different kinds of communication (synchronous and asynchronous). In

(4)

Consumer / Courier

Restaurant

API Gateway

Restaurant Web UI

Delivery Service Kitchen Service Restaurant

Service Order Service

Notification Service Accounting

Service

REST API

REST API REST API REST API REST API

REST API REST

API

Stripe Adapter

Twilio Adapter

Amazon SES Adapter

Fig. 2. FTGO initial architecture (including only some of the microservices)

this work, we consider a call as an action that demand the execution of a task or a list of tasks. From this perspective, we can say that a call is something that a service needs to do. And then, having multiple calls means performing a lot of work regardless the presence of a response or not.

B. The used platform and tools

To translate the FTGO microservice architecture into a graph, we chose to work with Neo4j as an implementation tool to create and analyze the obtained graph. Motivated by the benchmark and analysis studies performed by [10], [11] and [12], we concluded that Neo4j with its main three following tools is the most suitable for our case.

• Neo4j Browser [13]:is a development tool for querying, visualization, and data interaction.

• Neo4j Bloom [14]: is an easy-to-use graph exploration application for visually interacting with Neo4j graphs.

• Neo4j NEuler [15]: is the Graph Data Science Playground. It is a user interface that helps on boarding with the Graph Data Science Library that provides the graph algorithms.

C. The graph representation

To create the application graph, we analyzed the source code repository, many different figures that illustrate the decomposition strategy in addition to all the book’s chapters. We managed to distinguish between the different services, their relationships and the used types of communication. Finally, we used Neo4j Browser and Neo4j Bloom to create the graph illustrated in Figure 3.

In this representation, we have four kinds of services, each represented with a different color. The nodes in pink are the frontend services that receive the client requests. The reds are the backend services that do most of the work. Each service has its own database, represented in a beige color, except the ones that does not manipulate data. Finally, the green entities are adapters which allow to communicate with external APIs. Concerning the communication styles, the graph defines five types. Rest Service used to expose a Rest API to the other services. Domain Event to send events and perform changes across multiple aggregates avoiding database locks

Order DB Database

FrontEndMicroservice

IntegrationAdapter

Microservice 2

3

9 7

COMMAND_MESSAGE DATABASE_ADAPTER

DEPENDS DOMAIN_EVENT

3

3 9 7

REST_SERVICE 13

Api Gateway

Consumer

Delayed Order Service

Delivery

Delivery DB

Order History

Order History DB

Kitchen DB

Amaon_SES_Adapter

Twilio Adapter Notification

Restaurant Restaurant UI

Restaurant DB Order

Account

Stripe Adapter Account

DB Consumer

DB

Kitchen

Fig. 3. FTGO application graph.

and ensuring better scalability. Command Message which specifies executed operations and parameters using a service point-to-point messaging channel.Depends for using external APIs adapters, andDatabase Adapterfor databases. Each relationship is represented with a directed colored arrow holding as a label the type of the sending or receiving messages.

Once the FTGO application graph is ready, and before launching the graph data science library, an important step will be to remove database nodes from the graph because there is no significant value to get from them. Moreover, their presence will affect some results of the executed algorithms.

D. The obtained results and their interpretation

The first algorithm to execute is the degree centrality algorithm. Figure 4 presents an illustrative chart of the total number of outgoing calls by service.

/

Degree Degree_Out Degree and Degree_Out by Node

8

6

4

2

0

Api Gateway Order

Res taurant

Acco unt

Kitchen Order History

Consume r

Delayed Order Service Notification

Restaurant UI Delivery

Ama zon_S

ES_Adapter Stripe Adapter

Twilio Adapter Node

Degree and Degree_Out

Fig. 4. Centrality algorithms – Degree analysis.

For the Degree algorithm we choose a threshold of 5. We consider every service with a value greater than or equal to 5 to be a potentially chatty service detected by this algorithm.

Figure 4 shows 6 suspicious services. Those services send or receive 5 or more calls. We exclude the frontend services as they tend to have multiple connections with the backend services, which is totally normal.

(5)

/

Local_Clustring_Coefficient by Node

Node

Local_Clustring_Coefficient Consumer

Restaurant UI Delivery

Kitchen Order History Delayed Order Service

Order Restaurant Account

Api Gateway

0.0 0.2 0.4 0.6 0.8 1.0

Fig. 5. Community detection algorithms – Local clustering coefficient.

Figure 5 gives insights on the clustering coefficient. We get 8 services which have a value greater than or equal to 50%, and 6 with more than 60%. A node with 60% value means that this particular service tends to have connections with more than the half of the presented services in the architecture. Thus, we may consider those as potential chatty services. To mention that it is totally normal that frontend services tend to have a high value of the clustering coefficient.

Since, when a call comes to a frontend service, it is going potentially to make multiple calls to backend nodes in order to perform an action.

/

Degree and Local Clustering Coefficient by Node Degree

Node

Degree Local Clustering Coefficient

Dgr >= 5

Api Gateway Order

Restaurant Acc

oun t

Kitchen Order History

Consumer

Del ayed Order Service

Notification Restaurant UI

Delivery

Amazo n_SES_Adapter

Stripe Adapter Twilio Adapter 8

6

4

2

0

CC >= 50%

1.0

0.8

0.6

0.4

0.2

0.0 Local Clustering Coefficient

Fig. 6. Degree and local clustering coefficient combination.

An interesting idea is to combine the two previous algorithms. The resulting intersection gives an interval of chatty services highlighted by the two algorithms. Figure 6 shows 4 detected services, which means that they have a strong chance to be chatty.

The presented chart in Figure 7 combines the number of connections with the importance of the nodes. The idea is that if we have an important node with a large number of connections, the chart will indicate a high probability of being chatty. We have to precise that the importance score is based on the connection criteria. Thus, using the importance score proves the claims of the degree algorithm. In our case, six

/ 0.2

0.4 0.6 0.8 1.0

Api Gateway Order Restaurant

Acco unt Order History

Consume r

Amazon_SES_Adapter Stripe Adapter

Twilio Adapter Kitchen

Api Gateway Order

Account Order History

Consumer

Amazon_SES_Adapter Stripe Adapter

Twilio Adapter Kitchen

Restaurant

Node Node

Degree Degree

PageRank Eigenvector

Degree PageRank Degree and PageRank by Node

Degree Eigenvector Degree and Eigenvector by Node

PageRank >= 0.5

Kitchen

Eigenvector >= 7 8

6

4

2

0

8

6

4

2

0

14

12

10

8

6

4

2

0

Fig. 7. Degree and PageRank and Eigenvector combination.

services have a PageRank higher than or equals to 0.5, and 4 services combined with a degree greater or equals to 5. Five services have an Eigenvector greater than or equals to 7, and 4 services combined with the degree of 5 and more. We have one exception with theRestaurant UI frontend service that is being excluded by the Eigenvector algorithms.

Figure 8 measures the number of triangles in which a node participates. This allows having an idea on the degree of coupling of a node. And then, the cohesion of a community.

As a result, we have 4 services participating in 7 or more triangles with other nodes.

/

Consumer

Restaurant UI Delivery Kitchen

Order History

Order

Restaurant

Account Api Gateway

Node

Triangles Count

0 2 4 6 8 10 12 14

Triangles_Count by Node

Fig. 8. Community detection algorithms – Triangles Count.

After running the different algorithms on a graph with 14 nodes, the intersection of all the obtained results shows the following:

• 2 services accused by the 4 algorithms(Order, Kitchen).

• 2 services accused by 3 algorithms (Order, Kitchen).

• 1 service by 2 of the executed algorithms(Consumer).

In the most optimistic scenario, we have two chatty services, those selected by the four algorithms, and in a more critical way we can choose four services, or even add the fifth one as its statistics in the other algorithms were so close to be accused, and it will be interesting to consider it.

In order to find clusters in the graph, we can add another analysis that uses the community detection algorithms. Figure

(6)

9 shows the results of the Louvain algorithm. We have surrounded the 5 detected services with red circles in four detected communities. The first thing to mention is that three of the previous chatty detected services from the previous analysis are in the same community. Thus, a tight community exists in our graph and these services communicate a lot within their cluster. Moreover, we use the centrality Betweenness algorithms to detect bridges between groups. Interestingly, the three services have a high score, which means they tend to be bridges with multiple communities. On one hand, they have multiple connections in their community and in another, they have various relations with the outside, indicating a high chattiness in the graph. For the other communities, the algorithm tends to group the nodes that are attached to each other into one group.

Restaurant UI

Order

Kitchen Order History

Api Gateway

Notification

Amazon_SES_Adapter Twilio Adapter

/

Consumer Kitchen Order Restaurant

Account

Notification 0

5 10 15 20 25 30

Delivery

Node

Betweenness

Betweenness by Node

Order Consumer

Account Restaurant

Stripe Adapter

Kitchen Consumer

Fig. 9. Louvain community detection algorithm and centrality Betweenness

Initial results: We manage to find chatty services in the FTGO application. This later is considered as a reference microservice example that use many patterns and good practices in its design and implementation. Furthermore, the studied application uses the Domain Driven Design’s concepts and principles as a splitting approach. As a first conclusion, we can affirm that even if a microservice architecture was built and decomposed using the DDD’s principle, it may contain some architectural anti-patterns such as the distributed monolith in our case. The question we can ask now is: Is the obtained microservices decomposition using DDD the best we can have? Or can we get better results if doing some architectural refactoring?

To answer those questions, we choose to provide some changes on the previous architecture and test its quality. The detected problem in the FTGO application is the distributed monolith anti-pattern, i.e., big services connected with each other. The obvious solution to solve such a problem is to divide the concerned services into smaller entities. For this end, we have chosen one of the chatty services previously detected and we divided it into more functional services. Based on all the previous results, the selected microservices to be decomposed is Order service.

E. The new proposed microservice architecture

The new architecture:Dividing the Order service produces a mini order system. A communication between the legacy architecture and the new one must be established too. Figure 10 presents the new architecture with theOrder management system. Figure 11 shows in details the new Order system.

New Order System

Brokers Events Handler

Events Publisher

Order Events Updater Brokers

Commands Handler

Delegate Order

DB Delegate

Order Broker

Database

FrontEndMicroservice

IntegrationAdapter

Microservice 4

4

3

12 8 COMMAND_MESSAGE

DATABASE_ADAPTER DEPENDS DOMAIN_EVENT LISTEN

5

3 9 2 11

PUBLISH 1

REST_SERVICE 17

Order DB

Fig. 10. New architecture of the FTGO application.

Events Handler

Events Publisher

Order Events Updater Delegate Order

DB Order

DB

Commands Handler

Kitchen

Consumer Order

Restaurant UI Order Api

Update Order Create

Order Cancel

Order

Fig. 11. New order system.

We have split the Order service into three sub-services Create Order, Update Order, and Cancel Order. We have created two new frontend services to communicate with the new services as we do not want them to be connected to the legacy services. In order to avoid the rise of new anti-patterns, we tend to use some well-known patterns while splitting. For instance, we have used the asynchronous messaging based on the outbox pattern to send data to the other side of the architecture. Another technical choice was to link the three new order sub-services to one database. Roughly seen, it could be considered as an anti-pattern. However, in our situation, it is totally safe since every new introduced service has its own functionalities that does not overlap or cause inconsistencies or contradictions in the database level.

(7)

The new results and their interpretation: The next step is to redo the same experimentations on the new architecture to verify the relevance and reliability of the new introduced changes.

/

New Degree and New Degree_Out by Node

Node

New Degree and New Degree_Out

New_Degree New_Degree_Out 7

6

4

2

0 5

1 3

Api Gateway Restaurant

Accoun t Kitchen Order History

Consumer

Restaurant UI Delivery

Am azon_SES_Adapter

Stripe Adapter Twilio Adapter Comm

and Handler Delegate Order

Create Order Order Api Order Restaurant UI

Update Order Cancel

Order Event Publisher

Event Hand ler

Order Event Updater

Event Handler

Order Event Updater Event Publisher

Stripe Adapter

Cancel Order

Create Order Order Api

Order Restaurant UI Update Order

Command Handler Consumer

Kitchen

Restaurant UI Restaurant

Twilio Adapter Amazon_SES_Adapter Notification Account

Api Gateway

Delayed Order Service Order History

Delivery

Delegate Order

All nodes are Clean

Fig. 12. New architecture centrality algorithms – Degree analysis.

Figure 12 presents the Degree analysis for the new architecture. The chart shows that we have successfully created a new order management system with services that have a minimum degree number. The services detected by the algorithm with a number of connections higher than the threshold are those from the legacy system.

/

Prev_Degree and New_Degree by Node

Node

Prev_Degree and New_Degree

Prev_Degree New_Degree

4

2

0 8

6

Api Gateway Restaurant

Acc oun

t Kitchen Order

History Consumer

Restaurant UI Del

ivery

Amazo n_SES_Adapter

Stripe Adapter Twilio Adapter

Comm and Handler

Delegate Order Create Order

Order Api Order Restaurant UI

Update Order Cancel

Order

Event Publisher Event Hand

ler

Order Event Updater Order

Fig. 13. Degree analysis Comparison.

Figure 13 clearly shows that the degree analysis reveals a pure improvement.

/ R

New_Local_Clustring_Coefficient by Node

Node

New_Local_Clustring_Coefficient

0.0 0.2 0.4 0.6 0.8 1.0

Consumer Restaurant UI Delivery

Kitchen Order History Delayed Order Service

Delegate Order

Restaurant Account Api Gateway

Event Handler

Order Event Updater Event Publisher

Stripe Adapter

Cancel Order Order Api

Order Restaurant UI Update Order Command Handler

Consumer

Kitchen

Restaurant UI Restaurant

Twilio Adapter Amazon_SES_Adapter

Notification Account

Api Gateway

Delayed Order Service Order History

Delivery

Delegate Order

Independent new system

Create Order

Fig. 14. New architecture community detection – Local clustering coefficient.

Figure 14 shows 3 services with a value higher or equal to 50% instead of 8 in the prior. Having such results means that the nodes tend to have less communication than it was.

Focusing more on the graph, we can see that the Order management system entities have low values, which means that every service tends to communicate with its direct neighbors.

The comparison between the previous and the new clustering coefficient values in Figure 15 shows a big improvement.

Except the order service that is being removed, the majority of the services have shown smaller values. The peak in Delegate order node is totally normal as it is a new created service.

In order to be sure that the order management system independently works and that we separated it successfully from the previous architecture, we run the Louvain community detection algorithm. The obtained result in Figure 16 shows a success. The algorithm detects the new system as one community that work as an independent group.

V. RELATED WORK

In this section, we will present the main microservices anti- patterns contributions found in literature.

Actually, several works were interested in defining microservices anti-patterns. Tighlit et al. [16], Taibi and Lenarduzzi [17] executed multiple studies and provided a list of top detected anti-patterns. To come-up with such results, they followed different techniques such as paper reviews, professional interviews, project analysis and so on. [17] also proposed taxonomies that classify these anti-patterns into different cate-

(8)

/

Prev_Local_Clustering_Coefficient and New_Local_Clustering_Coefficient by Node

Node

Prev_Local_Clustering_Coefficient Next_Local_Clustering_Coefficient

0.0 0.2 0.4 0.6 0.8 0.1

0.0 0.2 0.4 0.6 0.8 0.1 Prev_Local_Clustering_Coefficient New_Local_Clustering_Coefficient

Consumer Restaurant UI Delivery

Kitchen Order History Delayed Order Service

Restaurant Account

Order Api Gateway Amazon_SES_Adapter

Command Handler Cancel

Order

Notification Delegate Order Create Order

Event Publisher Event Handler

Order Api Order Restaurant UI

Update Order Order Event

Updater Stripe Adapter

Twilio Adapter

Fig. 15. Local clustering coefficient comparison.

Event Publisher Event Handler Order Event Updater

Delivery Account

Stripe Adapter

Consumer

Order History Api Gateway

Delegate Order

Delayed Order Service

Restaurant UI Kitchen Restaurant

Notification

Amazon_SES_Adapter

Twilio Adapter Cancel Order

Create Order

Order Api Order Restaurant UI

Update Order Command Handler New separated

system

Fig. 16. New architecture Louvain community detection algorithm.

gories. To mention that all these contributions highlighted the boundary definitionproblem as one of the common dangerous challenges that gives birth to many anti-patterns.

Other researchers have proposed automatic techniques to detect anti-patterns. Pigazzini et al., [18] and Borges [19] focus on detecting anti-patterns that internally affect services using techniques such as code analysis and network theory.

Concerning the use of the graph theory to explore microservice architectures, Gaidels et al. [5] applied graph algorithms on an online banking system using the Neo4j set of tools.

The particularity of our work is that we used the same technique to provide scientific answers to the efficiency of one of the most used decomposition strategies, namely the decomposition by the DDD’ sub-domain pattern. We showed that even if this pattern is respected, the obtained architecture will not always be free of some anti-patterns such as the distributed monolith. From the other side, other proposals have just focused on traversing the network and detect its important nodes. More than that, we interpreted the algorithms’ results from the microservices vision and not just taking it only from the graph perspective.

VI. CONCLUSION ANDFUTURE WORK

In this paper, we aimed to confirm that the adoption of the DDD’s principles and concepts when decomposing the

microservices is not enough to obtain a consistent and free of anti-patterns architecture. Even if, from the practical perspective, there is no doubt that the sub-domain dividing technique is the best pattern we can follow. Hence, the necessity of continuously rethinking and improving every obtained architecture, with mentioning the architect’s responsibility to take the appropriate actions and decide the eventual changes.

In the future, we intend to validate these results on larger projects with giving more interest to the type of the relationships between the services and its potential impact on the experimental results. It would be also interesting to study other anti-patterns concerning other aspects of the microservices applications.

REFERENCES

[1] EVANS, Eric et EVANS, Eric J. Domain-driven design: tackling complexity in the heart of software. Addison-Wesley Professional, 2004.

[2] ERL, Thomas. Service-oriented architecture: concepts, technology, and design. Pearson Education Inc, 2005.

[3] MARTIN, Robert Cecil. Designing object-oriented C++ applications.

Prentice Hall, 1995.

[4] CONWAY, Melvin E. How do committees invent. Datamation, 1968, vol. 14, no 4, p. 28-31.

[5] GAIDELS, Edgars et KIRIKOVA, Marite. Service Dependency Graph Analysis in Microservice Architecture. In : International Conference on Business Informatics Research. Springer, Cham, 2020. p. 128-139.

[6] NEEDHAM, Mark et HODLER, Amy E. Graph Algorithms: Practical Examples in Apache Spark and Neo4j. O’Reilly Media, 2019.

[7] Neo4j, Inc. (2020). The neo4j graph data science library manual v1.6 . url: https://neo4j.com/docs/graph-data-science/current/. (accessed:

06.05.2021).

[8] RICHARDSON, Chris. Microservices patterns. Manning Publications Company,, 2018.

[9] microservices-patterns/ftgo-application. url:

https://github.com/microservices-patterns/ftgo-application (accessed:

06.05.2021).

[10] FERNANDES, Diogo et BERNARDINO, Jorge. Graph Databases Com- parison: AllegroGraph, ArangoDB, InfiniteGraph, Neo4J, and OrientDB.

In : DATA. 2018. p. 373-380.

[11] DOMINGUEZ-SAL, David, URB ÓN-BAYES, Peter, GIM ÉNEZ- VAN Ó, Aleix, et al. Survey of graph database performance on the hpc scalable graph analysis benchmark. In : International Conference on Web-Age Information Management. Springer, Berlin, Heidelberg, 2010.

p. 37-48.

[12] GUIA, José, SOARES, Valéria Gonçalves, et BERNARDINO, Jorge.

Graph Databases: Neo4j Analysis. In : ICEIS (1). 2017. p. 351-356.

[13] Neo4j browser user interface guide. url:

https://neo4j.com/developer/neo4j-browser/ (accessed: 06.06.2021).

[14] Neo4j bloom friendly graph database visualization, exploration and collaboration tool. url: https://neo4j.com/product/bloom/ (accessed:

06.06.2021).

[15] Neuler: No-code graph algorithms. url:

https://neo4j.com/developer/graph-data-science/neuler-no-code-graph- algorithms/ (accessed: 06.06.2021).

[16] TIGHILT, Rafik, ABDELLATIF, Manel, MOHA, Naouel, et al. On the Study of Microservices Antipatterns: a Catalog Proposal. In : Proceed- ings of the European Conference on Pattern Languages of Programs 2020. 2020. p. 1-13.

[17] TAIBI, Davide et LENARDUZZI, Valentina. On the definition of microservice bad smells. IEEE software, 2018, vol. 35, no 3, p. 56-62.

[18] PIGAZZINI, Ilaria, FONTANA, Francesca Arcelli, LENARDUZZI, Valentina, et al. Towards microservice smells detection. In : Proceedings of the 3rd International Conference on Technical Debt. 2020. p. 92-97.

[19] BORGES, Rodrigo et KHAN, Tanveer. Algorithm for Detecting Antipat- terns in Microservices Projetcs. SSSME-2019: Joint Proceedings of the Inforte Summer School on Software Maintenance and Evolution, 2019, p. 21-29.