Towards a Roadmap for the Migration of Legacy Software Systems to aMicroservice based Architecture

Hugo H. O. S. da Silva1, Glauco de F. Carneiro1 Miguel P. Monteiro2

1Programa de Pós-Graduação em Sistemas e Computação (PPGCOMP), Universidade Salvador (UNIFACS), Salvador41770-235, Brazil

2NOVA LINCS, Faculdade de Ciências e Tecnologia Universidade Nova de Lisboa (FCT/UNL), 2829-516 Caparica,Portugal

contato@hugohenrique.com.br, glauco.carneiro@unifacs.br, mtpm@fct.unl.pt

Keywords: monolithic legacy systems, exploratory study, microservices

Abstract: The migration of legacy software systems to a microservice based architecture is not a trivial task due to chal-lenges and difficulties as reported in the literature. The concept of microservices mainly consists in softwareorganized as a suite of small, modular, and independently deployed services that run on their own processesand communicate through well-defined, lightweight mechanisms to serve a business goal. However, the litera-ture is still incipient in relation to step-by-step guidelines supporting practitioners to accomplish the migrationfrom an existing, monolithic structure to a microservice based architecture. Goal: Discuss lessons learnedfrom the migration of legacy software systems to microservices-based architecture. Method: We conductedtwo studies (a pilot and a case study) aiming at characterizing the relevants steps of such guidelines. Results:We report the steps and challenges observed during the migration reported in this study. Conclusion: Weidentify at least three main phases that drive the migration process.

1 INTRODUCTION

Microservices is an architectural style based on theservice-oriented computing approach (Dragoni et al.,2017). Their main goal is to efficiently build andmanage complex software systems (Singleton, 2016).Among the main promises for the adoption of amicroservices-based architecture, we can list the fol-lowing: to yield cost reduction, quality improvement,agility, and decreased time to market. Microservicescan be compared to the software equivalent of Legobricks: they are proven to work, fit together appropri-ately, and can be an option to build up complex so-lutions in less time than with traditional architecturalsolutions (Singleton, 2016).

In the past, a representative number of legacy soft-ware systems moved to the cloud keeping the same ar-chitecture in the new infrastructure. The practical out-come of this fact is that most of these legacy softwaresystems have been originally placed in virtual machi-nes and deployed in the cloud, assuming the charac-teristics of resources and services of a traditional datacenter (Silva et al., 2019). This approach fails to re-duce costs, improve performance and maintainability(Toffetti et al., 2017).

The issue remains, of which steps that should befollowed to migrate a monolithic legacy system to amicroservices-based architecture. To the best of ourknowledge, despite the relevance of this topic, it hasdrawn the attention of just researchers (Kalske et al.,2017) (Leymann et al., 2016) (Taibi et al., 2017). Tofill this gap, we present the lessons learned of our ex-perience in the migration of two legacy systems. Thelessons learned are the result of a two-phase studyto address the following Research Question (RQ):Which steps should be performed to support the mi-gration of legacy software systems to microservices-based architecture? Availability of lessons learnedcan help practitioners from industry and academiain the migration of legacy systems to microservices.They can also contribute to encourage practitioners toembrace this challenge.

The rest of this paper is organized as follows. Sec-tion 2 discusses the main shortcomings of a mono-lithic legacy system and maps them to possible soluti-ons provided by the microservice-based architecture.Next, section 3 introduces a two-phase study. Section4 describes the first phase, which is a pilot study ai-med at identifying key steps of the migration processas well as improvement opportunities. Section 5 re-

ports on the second phase, which is a case study focu-sed on applying a reviewed and improved version ofthe steps performed in the first study. Section 6 pro-poses a migration roadmap based on the insights gai-ned from the pilot and case studies. Section 7 reportslessons learned. Section 8 discusses opportunities forfuture research and provides concluding remarks.

2 MONOLITHIC VSMICROSERVICES

The adoption of single executable artefacts ormonoliths with the corresponding modularization oftheir abstractions is based on the sharing of resour-ces of a specific computer system (memory, data-bases, files, among others) (Dragoni et al., 2017).Considering that components of a monolithic sys-tem depend on shared resources, they are not inde-pendently executable (Dragoni et al., 2017)(Richard-son, 2014a)(Richardson, 2014b). In general, mono-lithic systems of large size are not easily maintainedand evolved due to their inherent complexity (Dra-goni et al., 2017). In most cases, dealing with soft-ware bugs in these scenarios requires a strong jointeffort and is thus likely to have a negative impact onteam productivity (Dragoni et al., 2017). Add to thisthe fact that to add or update libraries are likely toproduce inconsistent systems that either do not com-pile/run or worse, misbehave (Dragoni et al., 2017).

Carrying out a change on a monolithic system en-tails the re-building of the whole application. Asthe system evolves, it becomes ever more difficultto maintain it and keep track of its original architec-ture1. This can result in recurring downtimes, speci-ally for large-sized projects, hindering development,testing, and maintenance activities (Dragoni et al.,2017). Monolithic systems under these conditions areprone to stop working and become unable to providepart or all of their functionality. They also suffer fromscalability issues.

In order to deal with the shortcomings of this typeof applications, and to handle an unbounded numberof requests, developers create new instances of themand split the load among these instances. Unfortuna-tely, this approach is not effective, since the increasedtraffic will be targeted only to a subset of the modules,causing difficulties for the allocation of new resourcesfor other components (Dragoni et al., 2017).

Microservices should be small and indepen-dent enough to allow the rapid development,

1https://www.thoughtworks.com/insights/blog/microservices-nutshell

(un)pluggability, harmonious coexistence and inde-pendent evolution. Microservices have been referredas a solution to most of the shortcomings of mono-lithic architecture. They use small services to removeand deploy parts of the system, enable the use of dif-ferent frameworks and tookits and to increase scala-bility and improve overall system resilience.

In the context of this paper, the "micro"prefix isn’treally too important. Rather than being about size, itrelates to keeping the various services separate. Thisbecomes important when working with hundreds ofservices. A microservice architecture can make useof the flexibility and better pricing model of cloud en-vironments (Balalaie et al., 2016).

To illustrate the advantages that stand out whenusing microservices, we next show a non-exhaustivelist: cohesive and loosely coupled services (Wolff,2016); independent implementation of each microser-vice and thus enhanced system adaptability (Millett,2015); independence of multifunctional, autonomousand organized teams that provide commercial valuein addition to improved technical characteristics (Mil-lett, 2015); independence of domain concepts (Wolff,2016); freedom from potential side effects (SPoF)across services; encouragement of the DevOps cul-ture (Balalaie et al., 2016), which basically repre-sents the idea of decentralizing skills concentrationinto multifunctional teams, emphasizing collabora-tion between developers and teams, ensuring reducedlead time and greater agility during software develop-ment.

3 A TWO-PHASE STUDY

Exploratory studies like the two-phase explora-tory study reported here are intended to lay thegroundwork for further empirical work (Seaman,1999). In this case, the goal to identify the relevantand effective steps for the migration of legacy sys-tems to a microservices-based architecture. This sec-tion describes its design and settings.

The present study aims to address the followingresearch question (RQ): What would be the setof effective steps to migrate legacy systems to amicroservices-based architecture? The specific rese-arch questions (SRQ’s) derived from the base RQ areas follows: SRQ1: How to find features in a legacyapplication so that they can be subsequently modu-larized and become a candidate to a microservice-based architecture? SRQ2: How to migrate the bestcandidate features to a microservice-based architec-ture?The study protocol followed for this study is as fol-

lows. The first author of this paper carried out thetasks of the reported study, after discussing the stra-tegies, experiences and impressions with the othertwo authors. To answer the research questions (pri-mary and secondaries), all steps registered by the firstauthor in manuscripts were analyzed.

To select suitable subject systems for the study, itwas decided that candidate applications should matchthe following characteristics: (1) be a legacy applica-tion, (2) have a monolithic architecture that does nothave its functionalities modularized, (3) show symp-toms of scattering and tangling, and (4) correspond tothe symptoms described by the Big Ball of Mud anti-pattern (Coplien and Schmidt, 1995).

We also outlined what was expected of the study’soutcomes. The evolved version was expected to bemore coherent than before the migration, be more lo-osely coupled and its modular decomposition shouldmore aligned to the services it provides (Newman,2015). We also expected to observe an increase inthe autonomy of developing teams within the organi-zation, as new functionalities can be localized withinspecific services (Newman, 2015).

3.1 Key Concepts from Domain DrivenDesign

We used key Domain-Driven Design (DDD) conceptsto accomplish the tasks of this study. DDD was usedto translate functionalities into domain and subdo-main and thereby support the migration.

A Bounded Context is a subsystem in the solu-tion space with clear boundaries distinguishing eachsubsystem (Evans, 2004). Bounded Context aids inthe separation of contexts to understand and addresscomplexities based on business intentions.

In the broad sense, Domain comprises all relevantknowledge relating to the problem that is intended tobe solved. It can refer to either the entire Business Do-main, or just a basic or support area. In a Domain, wetry to turn a technical concept with a model (DomainModel) into something understandable. The DomainModel is the organized and structured knowledge ofthe problem. It should represent the vocabulary andmain concepts of the problem domain and identify therelationships between the various entities. It is expec-ted to serve as a communication tool for all involved,giving rise to a very important concept in DDD, whichis Ubiquitous Language. The model could be a dia-gram, code examples or even written documentationof the problem. The important thing is that the Do-main Model must be understandable and easy to ap-proach by all people involved in the project.

A Context Map is a high-level diagram showing a

Figura 1: Entities and Associated Features Scattered andTangled in ePromo (Silva et al., 2019)

collection of connected contexts and the relationshipsbetween them (Evans, 2004). The goal of the ag-gregate root is to select the object that serves as the"root"of a group of other objects, in a abstract mannerof a Façade (Gamma, 1995) to represent the wholestructure. On the other hand, the value object cancomprise simple or composite values with a businessmeaning.

4 THE PILOT STUDY

The subject of the pilot study is ePromo, a system thatcomprises a typical example of a corporate/businesscoupon web system implemented in the PHP program-ming language for the management of outreach cam-paigns. The web server is Nginx, whose features in-clude the creation of personalized offers and issuanceof tickets made by the customer. All functionalitiesare implemented in a large artifact, connected to a sin-gle relational database (MySQL), whereas Memcachedis used as a memory cache system, including data re-lated to the sessions - signs of a monolithic applica-tion. Due to the sudden growth of demand for cou-pons, the application started to face problems in thisspecific component, which led to interruptions in thesystem operation.

The specific research question SRQ1 says: findfeatures to be subsequently modularized and turnedinto microservice candidates. To answer it, the par-ticipant applied a manual identification of candidatefeatures and their respective relationships, by na-vigating among the directories and files and iden-tifying the purposes of each class. Figure 1 illustra-tes the identified entities, which in the beginning ofthe pilot study were: Offer, OfferPoint, Ticket,Requirement, Timer, User, Company. By analysingthe features associated to these entities, we acquiredan initial perception of how they are tangled and scat-tered in the code. In fact, the functionalities are thereference to build the Context Map. It is worth menti-oning that it was possible to recognize the entities and

Figura 2: ePromo System Context Map in the Pilot Study(Silva et al., 2019)

the candidates for value object’s and aggregate rootsduring elaboration of the Context Map, on the basisof the information retrieved from the source code. Atthis time, we had the opportunity to spot code tigh-tly coupled to the web framework, right at the initialbrowsing stage.

The migration process was carried out one featureat a time, based on the list of features. We startedwith the functionality that would have lowest impactwhen compared to the others. This process facilita-tes the validation of boundaries set between featureswith the least risk of side effects. Considering thatthe business rules were scattered throughout the con-trollers with significant duplication, additional effortwas necessary to identify the various functionalitiesinvolved. Note that this is a manifestation of tangling.

During analysis, we noticed that artifactTicketsController had many responsibilitiesand its business rules seemed scattered. It neededextensive refactoring, including extraction of clearlayers for different levels of abstraction. Each layerwould be represented by a folder, which entailedstructural changes at that level, within the repository’ssource root. New directories were created for system:Application, Domain and Infrastructure. FolderApplication is to be devoid of business logic andmade responsible for connecting the user interface tothe lower layers. In sum, the application layer will beable to communicate with the domain layer, whichwill act as a sort of public API for the application.It will accept requests from the outside world andreturn answers appropriately. Folder Domain is toharbour all concepts, rules and business logic ofthe application, such as the user entity or the userrepository. These files will be stored accordingto the context identified in previous steps. FolderInfrastructure is to host the implementationsconcerning technical features, which provide sup-

Figura 3: ePromo Modularized Version (End of the PilotStudy) (Silva et al., 2019)

port to the layers above, namely persistence, andcommunication over networks.

The Command pattern (Gamma, 1995) encapsula-tes a request as an object, thereby parametrizing cli-ents with different requests, queue or log requests,and support undoable operations (Gamma, 1995). Weapplied Command to minimize coupling and dealwith the tangled code with scattered business rulesand identified in the controllers of the application. Ba-sed on TicketController, Command was used touncouple the controller from the user interface logic.When looking at the command objects, we should beable to spot the goal of the code snippet they enclose.The controller is intended to pass just the informationneeded by the command - CreatingTicket in thiscase - to forward to the handler, which is to handlethe acceptance of the command and complete its task.

Using Command brings several advantages. First,the functionality can run in any part of the application.Second, the controller will no longer have businessrules, doing just what is proposed above. Third, thetests are easier to make, as a result of decoupling. Thenew version of the modularized system is presented inFigure 3.

4.1 Lessons Learned from the PilotStudy

The experience gained in the pilot study enabled us toanswer the specific research question SRQ1. In Sec-tion 4, we point out the identification of functiona-lities faced difficulties due to lots of scattered clas-ses and duplicated business rules. This situation istypified as the Anemic Model anti-pattern2. There-fore, identifying business resources requires much ef-fort than otherwise would be the case.

During identification and mapping of businesscontexts, we noticed that despite the sudden growthof demand for coupons, the number of features can-didates for microservices is not necessarily indicative

2https://martinfowler.com/bliki/AnemicDomainModel.html

of the use of a microservice architecture. There is nota positive trade-off between the advantages of micro-services and the corresponding costs and effort requi-red to manage it (Singleton, 2016).

Although microservice approaches offer substan-tial benefits, the corresponding architecture requiresextra machinery, which may also impose substantialcosts (Singleton, 2016). This also gives rise to gre-ater complexity, which is incompatible with the rela-tive simple scenario now perceived through the mapof contexts. Therefore, a decision to carry out a mi-gration should consider the extra effort required towork with issues such as automated deployment, mo-nitoring, failure, eventual consistency, and other fac-tors introduced by a microservice architecture. In thecase of ePromo, we decided not to opt for the migra-tion, keeping it in its new modularized version, for theabove reasons.

The preliminary list of lessons learned reached atthis point comprises two main parts: part 1 is relatedto the restructuring of the legacy system to a modu-larized version and part 2 is related to the migrationof the modularized version, to microservices. Part 1of the lessons learned are related to the (1a) identifi-cation of candidate functionalities that can be modu-larized in legacy applications; (1b) analysis of rela-tionships and organizational dependencies in the le-gacy system; (1c) identification of each domain andsub-domain. Part 2 of the lessons learned relates tothe (2a) selection of the candidates according to theirimportance to the domain and the application itself;(2b) conversion of the candidate functionalities to mi-croservices.

5 THE CASE STUDY

In this case study, we aim at analyzing an effectivemanner to look for candidate features to be modula-rized in legacy software systems to be later migratedinto microservices. The subject system is eShop, anonline store in which users can browse a product ca-talog.

Figure 4 illustrates a typical scenario of eShop.The system provides functionalites such as userauthentication, catalogue of products, special offers,and payments. The features of the monolithic ap-plication are implemented in the PHP programminglanguage in a single "big module", connected to a(MySQL) relational database. The system runs as asingle artifact on a Nginx web server. The size ofthe source code increased dramatically over the ye-ars, as stakeholders asks for ever more changes andnew functionalities. To deal with such requests, de-

Figura 4: A Traditional Monolithic Legacy Software Sys-tem (Case Study) (Silva et al., 2019)

velopers struggled to deliver new releases, which de-manded ever more effort.

Part I of the process consists of migrating the le-gacy system to a modularized version. To carry it out,we first "manually"identified the candidate functiona-lities by navigating among the directories and files tofind out the goal of each artifact likewise the pilotstudy. Figure 4 shows the entities Identity, Basket,Marketing, Catalog, Ordering and Payment rela-ted to the identified functionalities. This is the out-come of the first step aimed at identifying the mainfunctionalities and responsabilities in view of a tenta-tive establishment of boundaries between them. Next,we planned to break down the main module into units.The key to this task was the use of Bounded Con-texts ans their respective relationships, as representedin Figure 5. We applied in each Bounded Context thefollowing DDD key concepts: aggregate root, valueobjects and domain services. These concepts supportthe challenge to deal with manage domain complexityand ensures clarity of behavior within the domain mo-del.

After the acknowledgement of contexts, we ordedthem by level of complexity, starting with the low le-vel ones to validate the context mapping. Moreover,we positioned the contexts into well-defined layers,expressing the domain model and business logic, eli-minating dependencies on infrastructure, user inter-faces and application logic, which often get mixedwith it. We managed to set all the code related todomain model in one layer, isolating it from the userinterface, application and infrastructure parts (Evans,2004). In some situations, we can apply the Stranglerpattern (Taibi et al., 2017) to deal with the complexityof the module to be refactored. Consiedering that fea-tures are moved to new modules or a new system, thelegacy system will be totally "strangled"to the pointwhere it will no longer be useful.

A folder should be created for each of the Boun-ded Contexts and within each folder, three new fol-ders should be added, one for each layer: Domain,Application, Infrastructure. They contain the

Figura 5: A Context Map for the Monolithic Legacy Soft-ware System (Case Study) (Silva et al., 2019)

Figura 6: An Evolved Monolithic Legacy System (CaseStudy) (Silva et al., 2019)

source code necessary for this Bounded Context towork. It is crucial to consider the domain modelsand their invariants and to recognize entities, valueobjects and also aggregate roots. We should main-tain the source code in these folders as describedin the sequence. Folder Application contains allapplication services, command and command han-dlers. Folder Domain contains the classes with exis-ting tactical patterns in the DDD, such as: Entities,Value Objects, Domain Events, Repositories,Factories. Folder Infrastructure provides tech-nical capabilities to other parts of the application, iso-lating all domain logic from the details of the infras-tructure layer. The latter contains, in more detail, thecode for sending emails, post messages, store infor-mation in the database, process HTTP requests, makerequests to other servers. Any structure and library re-lated to "the outside world", such as network and filesystems, should be used or called by the infrastructurelayer.

Part II of the process consists of migrating the mo-dularized version to a microservices-based version.At this point, the focus is on the analysis of the previ-ously developed Context Map and the assessment ofthe feasibility of decomposing each identified contextinto microservice candidates. In this case, during theanalysis of the Context Map, it is required to unders-tand and identify the organizational relationships anddependencies. This is analogous to domain modeling,

which can start relatively superficially and graduallyincrease levels of detail.

At this point, we wanted to decompose an appli-cation into smaller parts. The most common way todo this is based on layered segmentation based onuser interface, business logic and database responsi-bilities. However, this is prone to give rise to couplingbetween modules, causing the replication of businesslogic in the application layers (Dragoni et al., 2017)- coupling defines the degree of dependency betweencomponents or modules of an application. The micro-service proposal to circumvent this problem entailssegmenting the system into smaller parts with fewerresponsibilities. In addition, it also considers domain,focus and application contexts, yielding a set of auto-nomous services, with reduced coupling.

To provide answers to the specific research ques-tion SRQ2, the Bounded Contexts from DDD are usedto organize and identify microservices (Nadareishviliet al., 2016). Many proponents of the microservicearchitecture use Eric Evans’s DDD approach, as it of-fers a set of concepts and techniques that support themodularization in software systems. Among these to-ols, Bounded Context is used to identify and organizethe microservices. Evans made the case for Boun-ded Contexts as facilitating the creation of smaller,more coherent and more cohesive components (mo-dels), which should not be shared across contexts. Inthe Context Map shown in Figure 5, the arrow is usedto facilitate identification of upstream/downstream re-lationships between contexts. When a limited contexthas influence over another (due to factors of a less te-chnical nature), provision of some service or informa-tion this relationship is considered upstream. Howe-ver, the limited contexts that consume it comprise adownstream relationship (Evans, 2004).

An effective way of defining microservice boun-daries entails correctly identifying the Bounded Con-texts, using DDD and breaking a large system acrossthem. Newman points out that Bounded Contexts re-present autonomous business domains (i.e., distinctbusiness capabilities) and therefore are the appropri-ate starting point for identifying boundaries for micro-services. Using DDD and Bounded Contexts lowersthe chances of two microservices needing to share amodel and corresponding data space, risking a tightcoupling.

Avoiding data sharing facilitates treating each mi-croservice as an independent deployment unit. Inde-pendent deployment increases speed while still main-taining security within the overall system. DDD andBounded Contexts seems to make a good process fordesigning components (Newman, 2015). Note howe-ver, that it is still possible to use DDD and still end

Figura 7: A New Based Microservices Software System(Case Study) (Silva et al., 2019)

up with quite large components, which go against theprinciples of the microservice architecture. In sum,smaller is better.

The number of responsibilities is an important ser-vice feature. This is reinforced by the Single Respon-sibility Principle (SRP) (Martin, 2002). Each servicemust have a well-defined boundary between the mo-dules, which should be independently created and pu-blished, through an automated deployment process. Ateam can work on one or several Bounded Contexts,with each serving as a foundation for one or severalmicroservices. Changes and new features are suppo-sed to related to just one Bounded Context and thusjust one team (Wolff, 2016).

The strategy is to move resources vertically by de-coupling the primary feature along its data and redi-rect all front-end applications to the new APIs. Ke-eping all data on a single basis is contrary to the de-centralized data management feature of microservi-ces. Having multiple applications using the data froma centralized database is the primary step to decouplethe data along with the service.

During the migration of the eShop database, wedecided to execute it in incrementar steps due to itsinherent complexity. Migrating data from a legacysoftware system requires careful planning, dependingon each case. In the case of the aforementioned da-tabase, we identified the tables corresponding to eachservice and created a new database schema (MySQL)for each of the corresponding services. We then mi-grated one service at a time. The database did notseem to be particularly large and this approach wasapplied without side effects. However, this may notbe the best approach, depending on the size of the da-tabase to be migrated. Each specific scenario must beanalyzed addressing their own specificities and com-

plexities scenarios. To perform the migration, weadopted the Doctrine Migrations3 tool. Figure 7 con-veys the architecture of the new microservices basedarchitecture system.

6 PROPOSED MIGRATIONROADMAP

The purpose of the roadmap is to migrate a systemwith monolithic legacy architecture to a microservicearchitecture. A level of discipline and some skills arenecessary in the operational part, as described in thenext sections.

Traditional monolithic legacy software systemsusually show signs of deficient modularity, resultingin significant levels of tangling and scattering. Mostof the time, a complete system rewrite from scratch isinfeasible. It is therefore recommended to migrate thelegacy system gradually, replacing specific parts of itwith new modules. This type of approach is alreadydiscussed in the Strangler pattern (Taibi et al., 2017).

Upon completing the migrating process, the olderversion of the legacy system is discarded. Therefore,it is important to note that this approach helps mini-mize risk during migration and distributes develop-ment effort over time.

6.1 Roadmap Premises

A first assumption or requirement to use the proposedroadmap, is that the target system has a monolithicarchitecture. At least three layers should be identifiedon it: presentation layer, business layer and data layer.It is also important that the developer or developmentteam have a minimum knowledge of the system’s bu-siness rules, which will be critical during execution ofphases 1 and 2, which focus on the extraction of kno-wledge from the domain and on establishing limitsconsistent with the system’s business rules.

Fast Deployment. How the microservice archi-tecture promotes the creation of independent services;it is necessary to automate the deployment of theseservices to save time for developing teams in differentenvironments, e.g., development, testing and produc-tion environments.

Provisioning Environments. Given the need toautomate the deployment process, we also feel theneed of a fast provisioning environment, which fitsnicely with Cloud Computing.

The structure of the roadmap is as follows. Phase1 analyzes and identifies of key functionalities and

3https://www.doctrine-project.org/projects/migrations.html

Figura 8: Roadmap Premises Workflow

their respective responsibilities. Phase 2 details thepre-existing characteristics of the monolithic system,using some of the key concepts of Domain-Drive De-sign (DDD), such as: Delimited Context, ContextMap, Domains, Subdomains, Aggregator, Value Ob-jects, and Services Domain. These concepts help tobuild artifacts that support migration decisions to bemade, including granularity and cohesion of servicesto be implemented. Phase 3 promotes the migration toa microservice architecture of the Bounded Contextsidentified and mapped in the previous phase.

6.2 Phase 1: Monolithic Software

Step 1: Analyze Source Code and DatabaseInput Data: Source Code and DatabaseOutput Data: Source Code and DatabaseDescription of Step 1: The first phase is initia-

ted by the process of identifying the artifacts in thesystem. This step analyzes the source code and thedatabase legacy system. To perform this analysis it isnecessary to navigate between the files and directoriesof the system, to obtain a clearer view of the domainunder analysis.Step 2: Identify Main Functionalities

Input Data: Source Code and DatabaseOutput Data: List of Identified FuncionalitiesDescription of Step 2: This step identifies the

purposes, responsibilities and main functionalities ofthe artifacts. It is important to emphasize that thisis an iterative and incremental process. At this firststage, it is essential to document it, even if it meanssimply using a list to record what was identified while

Figura 9: Simple Draft Diagram with Subdomains Identi-fied

browsing the system artifacts. The next step is to es-tablish a temporary boundary between the various fe-atures, where the goal is to ensure more clarity andunderstanding of the system’s business rules.

6.3 Phase 2: Pre-ExistingCharacteristics of MonolithicSoftware

Step 3: Identify Domains and Subdomains of MappedFunctionalities

Input Data: List of Identified FuncionalitiesOutput Data: Diagram with Identified Subdo-

mainsDescription of Step 3: In this step, the goal is

to distill the domain to provide an ever deeper kno-wledge. Therefore, it is important to create a domainmodel, which is a high-level artifact that reveals andorganizes domain knowledge data with the intent ofproviding clear language for developers and domainexperts. This effort can be collaborative, involvingthe development team and domain specialists and sta-keholders. It is important for this task to comprise theoutlining of a simple diagram, without formalities, asits goal is to be clear and increase knowledge of thebusiness domain functions.

Often, the source code is coupled to the Web ap-plication structure. Therefore the task of identifyingthe functionalities needs to be reviewed a few times,so that boundaries of domains and subdomains re-ceive a proper validation.

The diagram of the domain model from Figure9 includes real-world objects such as: ProductReturn, Product, Address, Payment among others.

Figura 10: Example of a Split Domain into Four BoundedContexts

These objects can have different behaviors, so somefunctionalities of the product and payment mayvary. For instance, upon payment of a product theonly important information for the operation to beperformed is identification of the product. Therefore,it may be more interesting to create distinct modelsthat represent the same object in the real world. Thisway, each model can meet the specific needs of itscontext.

Step 4: Identify Bounded ContextsInput Data: Diagram with Identified SubdomainsOutput Data Identified Bounded ContextsDescription of Step 4: As illustrated in Figure 10

with the concept of Bounded Context, it is possible toset limits to a specific domain according to businessintentions (Marketing, Sales, Purchase and Stock).

As domains and subdomains are identified andfilled in the diagram, it is important to classify theessential functionalities from business and theirexisting relationships. At this stage, no concernshould relate to implementation details. The focus isstill on the domain knowledge.

Step 5: Build a Context MapInput Data: Identified Bounded ContextsOutput Data: Context MapDescription of Step 5: Once the Bounded Con-

texts Mapping is done, the next step is to build a Con-text Map. The goals of this map is to make explicit theunderstanding of contexts and relationships betweenthem. As well as the mapping of the Bounded Con-texts, the Context Map also needs to have a continuousprocess of improvement, so that the information of theBounded Contexts and consequently the Context Mapis improved.

In this stage of the migration it is possible to iden-tify, based on the tactical modeling of DDD, possi-

ble candidates for entities, objects of value, services,among others.

The main focus of the first and second phases isthe extraction of knowledge from the domain, iden-tifying the main functionalities and responsibilities inview of establishing coherent and validated limits ba-sed on the system’s business rules.

6.4 Phase 3: Target SoftwareArchitecture

The focus of this phase is on the decision and imple-mentation of the architecture. The first step of thisphase is to decide whether the system architecturewill be migrated to a microservice architecture. Thisis a decision that is up to the development team, whofrom the defined Context Map, can assess the comple-xity of the system, and whether there really is a needto migrate to a microservice-based architecture.

As described in the pilot study, it was noticedduring Context Map analysis that the system hadonly three contexts: Identity Context, OfferContextand TicketContext. Because it is a simple systemwith a reduced number of contexts, it was decided tomaintain the monolithic architecture, in view of theprogress achieved in the modularization through theapplication of DDD concepts. One of the reasons forchoosing not to migrate to a microservice architecturewas to avoid increasing the system’s complexity,which would be a consequence of implementing tothis architecture. Therefore, the number of contexts isa factor to be taken into account during this decisionmaking. However, we do not go as far as to set athreshold value for a minimum number of contexts.

Step 6: Migrate for Microservices ArchitectureInput Data: System with Evolved Monolithic Ar-

chitectureOutput Data: System with Microservices Archi-

tectureDescription: deciding to migrate to a microser-

vice architecture entails initiating a series of actions.First, note that in a scenario of a large application in acomplex domain, it is very common to observe manycontexts. Deciding on which context to start carryingout the migration is not a trivial task. An effectivestrategy is to select contexts that have no or few re-lationships. The number of bugs associated with aparticular context may also be a factor.

For each Bounded Context a directory must be cre-ated, within each of the directories, three new direc-tories must be added, one for each layer: Domain,Application, Infrastructure. They must containthe necessary source code for the Bounded Context to

work. It is essential to consider the domain modelsand their invariants and recognize Entities, Value Ob-ject’s and also Aggregates. The source code must bemaintained in these directories as described in the se-quence. The Application directory should containall application services and command handlers.

The Domain directory contains classes with exis-ting tactical patterns in DDD as: Entity, ValueObject, Domain Event, Repository and Factory.The Infrastructure directory should provide thetechnical resources for other parts of the application,isolating all domain logic from the details of the in-frastructure layer.

The infrastructure layer should contain in detailthe code for sending emails, sending messages, sto-ring information in the database, processing HTTP re-quests, and make requests to other servers. Any struc-ture and library related to the external world, such asnetwork and file systems, must be used or called atthe infrastructure layer.

The directory structure of a Bounded Contextshould be organized as follows:

+--src| +-- LegacySystem| +-- Context| +-- Application| +-- Domain| +-- Infrastructure+-- tests

In the scenario where the migration of architectureto microservices must take place, the Bounded Con-texts will play a key role in identifying and organizingthe microservices.

It is essential that each service has its ownstructure allowing separate maintenance externalrepositories. This facilitates the development andimplementation of adjustments that can be madeseparately, avoiding possible side effects (SPOF)other services. It is prudent to organize the contextsin well-defined layers, because this way allows usto express the domain model and business logic,eliminating dependencies on infrastructure, userinterface and application logic, concepts that oftenare mixed. Everything that is related to the domainmodel must be concentrated on a layer, isolating itfrom the top layers, such as the user interface layer,application layer, and infrastructure (Evans, 2004).

Step 7: Run Unit and Integration TestsInput Data: Migrated Bounded ContextOutput Data: Migrated Bounded Context with

Executed TestsDescription: As the Bounded Contexts are being

migrated, it is recommended that automated testing be

performed, initially unit testing. The intent is ensurethat the implemented parts are working as expected.

These three phases make up the core minimum setto perform a migration. There is the possibility of in-cluding new steps in one or more of the three phases,depending on the specific characteristics of the soft-ware system in question.

7 LESSONS LEARNED

As a result of the experience of the two-phase studypreviously reported, we highlight four key challengesfaced during the migration. The first challenge is theidentification of functionalities. It is not a trivial task,especially when considering large modules with scat-tered and tangled functionalities. The literature hasalready discussed this relevant issue in the migrationprocess (Ossher and Tarr, 2002). The second chal-lenge comes from the need to define optimal bounda-ries among candidate features for microservices. Thethird challenge comes from the need to decide whichwill befeatures should be converted to microservices.The fourth challenge is related to the need to carefullyanalyze these potential candidate microservices withrespect to their respective granularity and respectivecohesion.

Previous published work already addressed thedecomposition problem for identifying modules, pac-kages, components, and "traditional"services, mainlyby means of clustering techniques upon design arti-facts or source code. However, boundaries betweenmodules defined using these approaches were flexibleenough to allow the software to evolve into instan-ces of Big Ball of Mud (Coplien and Schmidt, 1995).Although the discussion in the literature regarding thevalue of cohesive services and the power of BoundedContexts, it seems to a void in the guidance on howto identify these in practice (McLarty, ). The mainissue is that those people trying to determine serviceboundaries are technologists looking for a technolo-gical solution. On the other hand, defining cohesive,capability-aligned service boundaries instead requiresdomain expertise. To overcome this difficulty, a mo-delling exercise should be carried out independentlyof the specific technology used (Silva et al., 2019).

We managed to derive multiple autonomous mi-croservices, each with its own database, by applyingthe strategies reported above. For communicationbetween the microservices, we used HTTP communi-cation mechanisms as API Restful and also asynchro-nous communication with an EventBus implementa-

tion, running RabbitMQ4. As shown in figure 7, eachof the microservices now work with an independentrelational database, except the Marketing service be-cause it is an auxiliary service. For this one, we choseto use an in-memory database (Silva et al., 2019).

8 CONCLUSIONS

It should be noted that migrating a legacy applicationrarely can be performed without significant effort. Itis often entails hard and complex work. To the bestof our knowledge, there are frameworks that can beused to support practitioners during the development(forward engineering) of microservice-based systems,such as Spring Cloud 5 and Hystrix 6, just to name afew. However, none of them provides full support tothe three migration phases. To contribute to filling thisgap, this paper presents the lessons learned to supportthis kind of migration. We believe that the availabi-lity these lessons learned can support and encouragepractitioners from the industry and academia to per-form them.

The lessons learned were based on our experienceon the two-phase study reported in this paper. We alsoplan to conduct a survey with practitioners from theindustry. Among other things, we wish to collect opi-nions their perceptions regarding the challenges thatare faced during this type of migration, learn aboutthe requirements and characteristics for suitable pro-cesses.

REFERENCES

Balalaie, A., Heydarnoori, A., and Jamshidi, P.(2016). Microservices architecture enables de-vops: migration to a cloud-native architecture.IEEE Software, 33(3):42–52.

Coplien, J. O. and Schmidt, D. C. (1995). Pattern lan-guages of program design. ACM Press/Addison-Wesley Publishing Co.

Dragoni, N., Giallorenzo, S., Lafuente, A. L., Maz-zara, M., Montesi, F., Mustafin, R., and Safina,L. (2017). Microservices: yesterday, today, andtomorrow. In Present and Ulterior Software En-gineering, pages 195–216. Springer.

Evans, E. (2004). Domain-driven design: tacklingcomplexity in the heart of software. Addison-Wesley Professional.

4https://www.rabbitmq.com5http://projects.spring.io/spring-cloud/6https://github.com/Netflix/Hystrix

Gamma, E. (1995). Design patterns: elements of reu-sable object-oriented software. Pearson Educa-tion India.

Kalske, M., Mäkitalo, N., and Mikkonen, T. (2017).Challenges when moving from monolith to mi-croservice architecture. In Current Trends inWeb Engineering, pages 32–47. Springer, Cham.

Leymann, F., Breitenbücher, U., Wagner, S., and Wet-tinger, J. (2016). Native cloud applications: Whymonolithic virtualization is not their foundation.In Cloud Computing and Services Science, pages16–40. Springer, Cham.

Martin, R. C. (2002). The single responsibility prin-ciple. The principles, patterns, and practices ofAgile Software Development, 149:154.

McLarty, M. Designing a microservice system.Millett, S. (2015). Patterns, Principles and Practices

of Domain-Driven Design. John Wiley & Sons.Nadareishvili, I., Mitra, R., McLarty, M., and

Amundsen, M. (2016). Microservice Architec-ture: Aligning Principles, Practices, and Cul-ture. "O’Reilly Media, Inc.".

Newman, S. (2015). Building microservices: de-signing fine-grained systems. "O’Reilly Media,Inc.".

Ossher, H. and Tarr, P. (2002). Multi-dimensional se-paration of concerns and the hyperspace appro-ach. In Software Architectures and ComponentTechnology, pages 293–323. Springer.

Richardson, C. (2014a). Microservices: Decompo-sing applications for deployability and scalabi-lity.

Richardson, C. (2014b). Pattern: Monolithic archi-tecture. Posjeceno, 15:2016.

Seaman, C. B. (1999). Qualitative methods in empiri-cal studies of software engineering. IEEE Tran-sactions on software engineering, 25(4):557–572.

Silva, H., Carneiro, G., and Monteiro, M. (2019). Anexperience report from the migration of legacysoftware systems to microservice based architec-ture. In Information Technology-New Generati-ons (ITNG 2019), pages 159–165. Springer.

Singleton, A. (2016). The economics of microservi-ces. IEEE Cloud Computing, 3(5):16–20.

Taibi, D., Lenarduzzi, V., and Pahl, C. (2017). Pro-cesses, motivations, and issues for migrating tomicroservices architectures: An empirical inves-tigation. IEEE Cloud Computing, 4(5):22–32.

Toffetti, G., Brunner, S., Blöchlinger, M., Spillner,J., and Bohnert, T. M. (2017). Self-managing

cloud-native applications: Design, implementa-tion, and experience. Future Generation Com-puter Systems, 72:165–179.

Wolff, E. (2016). Microservices: Flexible SoftwareArchitecture. Addison-Wesley Professional.