2017 24th Asia-Pacific Software Engineering Conference

From Monolith to Microservices: A

Dataflow-Driven Approach
Rui Chen Shanshan Li Zheng Li
Software Institute Software Institute Software Institute
Nanjing University Nanjing University Nanjing University
Nanjing, Jiangsu, P.R.China Nanjing, Jiangsu, P.R.China Nanjing, Jiangsu, P.R.China
Email: [email protected] Email: [email protected] Email: [email protected]

Abstract—Emerging from the agile practitioner communities, becoming an alternative way that overcomes the challenges of
the microservice-oriented architecture emphasizes implementing monolithic architecture, by decomposing the monolith into a
and employing multiple small-scale and independently deployable set of small services and making them communicate with each
microservices, rather than encapsulating all function capabilities
into one monolithic application. Correspondingly, microservice- other through light weight mechanism (i.e. RESTful API). As
oriented decomposition, which has been identified to be an defined by Martin Fowler et al. [2], microservices architecture
extremely challenging and complex task, plays a crucial and pre- is a new architectural style with nine characteristics, e.g.,
requisite role in developing microservice-based software systems. “Componentization via Services”. Nevertheless, Newman [3]
To address this challenge and reduce the complexity, we proposed advocates thinking of microservices as a particular approach
a top-down analysis approach and developed a dataflow-driven
decomposition algorithm. In brief, a three-step process is defined: for SOA (Service-Oriented Architecture) and also defines
first, engineers together with users conduct business requirement microservices by seven principles, including “Model around
analysis and construct a purified while detailed dataflow diagram business concepts”, “Decentralize all the things”, “Make ser-
of the business logic; then, our algorithm combines the same vices independently deployable” [4].
operations with the same type of output data into a virtual ab- Despite no consensus on the relationship of microservices
stract dataflow; finally, the algorithm extracts individual modules
of “operation and its output data” from the virtual abstract and SOA currently, the advantages of microservices are com-
dataflow to represent the identified microservice candidates. We monly accepted both in academia and industry, i.e. main-
have employed two use cases to demonstrate our microservice tainability, reusability, scalability, availability and automated
identification mechanism, as well as making comparisons with deployment [5], [6]. Netflix, Amazon and eBay all have
an existing microservice identification tool. The comparison and migrated their applications from monolithic architecture to
evaluation show that, our dataflow-driven identification mecha-
nism is able to deliver more rational, objective, understandable microservices architecture, so as to enjoy the advantages that
and consistent microservice candidates, through a more rigorous microservices architecture brings about. For example, Netflix,
and practical implementation procedure. which is a famous video streaming service, can deal with
Keywords—microservices, monolith, decomposition, data flow, one billion calls every day now by its streaming API in
business logic microservices architecture [7].
The microservices architecture is not a panacea and there
I. I NTRODUCTION are many issues need to be addressed, among which the most
Monolithic Architecture (MA) [1] is the traditional way important one is how to effectively decompose a monolithic
for software development, which used to be employed by application into a suite of small microservices, for the reason
world-famous Internet services such as Netflix, Amazon and that the decomposition process is usually implemented by hand
eBay, and it advocates encapsulating all functions in one [8]. Furthermore, the absence of sound evaluation methodol-
single application. Less complicated monolithic applications ogy aggravates the challenges of microservice-oriented decom-
have their own strengths, for instance, simple to develop, positions.
test, deploy and scale. Nevertheless, successful applications To address the abovementioned issues, we proposed a
are always growing in size and will eventually become a purified dataflow-driven mechanism that can guide ratio-
monstrous monolith after a few years. Once this happens, nal, objective and easy-to-understand microservice-oriented
disadvantages of the monolithic architecture will outweigh decomposition. Correspondingly, this work makes a three-
its advantages, for example, overwhelmingly complex and fold contribution: Firstly, this purified dataflow-driven mech-
incomprehensible code base of the monolith may hold back anism essentially provides a systematic methodology for
bug fixes and feature additions; the sheer size of the monolith microserivce-oriented decomposition. Secondly, compared to
can slow down the development and become an obstacle to the manual implementations [8], our algorithm-driven semi-
continuous deployment because of the longer start-up time. automated process significantly reduces the complexity in the
Microservices Architecture (MSA), emerging from agile decomposition practices. Thirdly, the two cases demonstrated
developer communities, is starting to take shape and now in this paper can act as a tutorial to help get familiar with our

978-1-5386-3681-7/17 $31.00 © 2017 IEEE 466

DOI 10.1109/APSEC.2017.53
microservice-oriented decomposition mechanism. composition approach can deliver more rational, objective, and
The rest of this paper is organized as follows. Section II easy-to-understand results.
briefly summarizes the related work. Section III introduces
B. Beyond Microservice-oriented Decomposition
the design and implementation of the data flow diagram driven
mechanism we proposed for microservices decomposition. In Service-oriented (de)composition in traditional SOA has
Section IV, we elaborate our case studies on microservice- been a hot topic for decades [15], [16], with two differences
oriented decomposition by employing the dataflow-driven ap- to decomposition under microservices architecture. One is that
proach. The evaluation of our decomposition mechanism and services are coarse-grained in SOA, but usually more fine-
some limitation discussions are specified in Section V. In grained in microservices architecture. The other one is that
Section VI, we draw conclusions of this study and also list decomposition in SOA often aims at selecting the optimal
potential future work directions. composed service from all possible service combinations
regarding some quality requirements, which is a bottom-up
II. R ELATED W ORK process; while in MSA the decomposition procedure may
cover the top-down partition first and then the bottom-up
A. Microservice-oriented Decomposition integration.
Microservice-oriented decomposition is a prerequisite in As a top-down method, Data Flow Diagram (DFD) [17] is a
migration to microservices architecture. The decomposition good choice for representing monolithic applications from the
process can be represented by the Y-axis of the scalable cube perspective of business processes [18]. Adler [19] presented an
[9]: split the application into small chunks to achieve higher algebra formalizing the decomposition procedure of data flow
scalability. As mentioned above, decomposing monolithic ap- diagrams, however, it has some drawbacks like inefficiency
plications into microservices can bring many benefits more and no guarantee on finding a good decomposition. Arndt et
than scalability in theory, while the commonly manual and al. [20] improved Adler’s work by replenishing new criteria
complex decomposition process [8] will prevent the practices and implementing their own algorithm for the decomposition
from achieving those benefits. Consequently, it is of great im- of data flow diagrams. Both of these two studies equally lack
portance to overcome this challenge and realize more effective assessments on decomposition result except for the intuitive
microservice-oriented decomposition. notion.
In the past three years, some researchers have devoted to Compared with the abovementioned studies, we transformed
addressing the problems of partitioning the application into the traditional DFD to a purified and detailed version, rather
microservices. Richardson [10] provided four decomposition than other SSAs [14] that are difficult to be transformed objec-
strategies, i.e. “decompose by business capability”, “Decom- tively for decomposition. Moreover, we designed an algorithm
pose by domain-driven design sub domain”, “Decompose by to support the two phases’ automation in our decomposition
verb or use case” and “Decompose by nouns or resources”. approach: (1) condensing the purified DFD to a decomposable
To the best of our knowledge, the former two are the most DFD and (2) identifying microservice candidates from the
abstract patterns which require human involvement and a decomposable DFD. We also conducted two case studies of
decision making [11]; while the latter two are easier to realize microservice-oriented decomposition, and demonstrated the
automation as long as criteria have been predefined. Moreover, effectiveness of our decomposition approach by evaluation and
as mentioned by Vresk et al. [12], an application might comparison to an existing decomposition tool.
use a combination of verb-based and noun-based decompo-
III. DATAFLOW-D RIVEN M ICROSERVICE - ORIENTED
sition. Disappointingly, this method was not implemented in
D ECOMPOSITION M ECHANISM
their study. Hassan et al. [13] offered an architecture-centric
modeling concept for microservitization, without mapping the As mentioned previously, to address the challenge and
microservices constituents in models to concrete microservices reduce the complexity in microservice-oriented decomposi-
source code and verifying its feasibility. Gysel et al. [14] tion, we developed a semi-automatic mechanism to break
proposed an service decomposition method on the base of business logics into microservice candidates. This mechanism
16 coupling criteria extracted from literature and industry comprises three steps including one manual step of dataflow
experience. Clustering algorithms are applied to decompose purification and two automatic steps of dataflow-driven de-
an undirected, weighted graph, which is transformed from composition, as specified below.
Software System Artifacts (SSAs). Yet some processes of Step-1. Construct a purified DFD.
the decomposition approach, especially score the edge of the As part of the requirement analysis, a purified DFD
aforementioned graph, lack objectivity. Besides, the transfor- is constructed manually to illustrate the detailed data
mation from SSAs to predefined, structured input increases the flow according to some business logic extracted from
complexity in microservice-oriented decomposition. users’ natural-language descriptions. The construction
In contrast, the microservice-oriented decomposition ap- of a purified DFD can start from establishing a
proach proposed in our work is driven by data flow diagrams traditional DFD and applying our predefined rules
from business logic. Based on the objective operations and (cf. Section III-A2). In particular, the so-called puri-
data extracted from the real-world business logics, our de- fied DFD focuses on data’s semanteme and operation

467
 only, while excluding the side information like data Algorithm 1 Microservice-oriented Decomposition Algorithm
store and external entities that are usually included in Input: PDF: the purified DFD
traditional DFDs. Output: Candidate microservice list
Step-2. Condense the purified DFD into a decomposable 1: function G ET D ECOMPOSABLE DFD(PDF)
2:  combine same operations and its output data
DFD. 3: DS ← ∅  DS : the data set of decomposable DFD
By combining the same operations with the same 4: PS ← ∅  P S : the operation set of decomposable DFD
type of output data, the function GetDecompos- 5: for P ∈ P DF.operation set do
6: if P ∈ P S then
ableDFD(PDF) in Algorithm 1 can automatically 7: new Pn  Pn : new operation
condense the detailed dataflow specified in the purified 8: new CDn  CDn : new composed data node
DFD into a decomposable dataflow. It is noteworthy 9: CDn .input ← CDn .input ∪ Pn
10: Pn .input ← Pn .input ∪ P.input
that the combination of the output data from the same 11: Pn .output ← CDn
operations in the purified DFD essentially realizes the 12: DS ← DS ∪ CDn
improvement of reusability of the potential microser- 13: P S ← P S ∪ Pn
14: else
vices delivered in the next step. 15: Pe ← P S[i]  Pe : exist operation
Step-3. Identify microservice candidates from the decom- 16: CDe ← Pe .output  CDe : exist composed data node
posable DFD. 17: CDe ← CDe ∪ P.output
18: Pe .input ← Pe .input ∪ P.input
Given a previously-generated decomposable DFD, 19: end if
the function GetMicroservices(DDF) in Algorithm 20: end for
1 can automatically extract individual modules of 21: new DDF  DDF : new decomposable DFD
22: DDF.data set ← DS
operation and its output data from the decom- 23: DDF.operation set ← P S
posable data flow. The separation of the modules 24: return DDF
eventually completes and represents the dataflow- 25: end function
26:
driven microservice-oriented decomposition, while 27: function G ET M ICROSERVICES(DDF)
each module indicates a potential microservice to be 28:  identify microservices from decomposable data flow diagram
developed or considered. 29: SS ← ∅  SS : service set
30: for P ∈ DDF.operation set do
We further elaborate the two phases in the following sub- 31: new S  S : new service
sections. 32: S.operation ← P
33: S.data set ← P.output
34: SS ← SS ∪ S
booking air book air schedule ready air 35: end for
flight list ticket list ticket flight 36: return SS
ticket
37: end function
38:
flight list expenditure air tickets 39: return GetMicroservices(GetDecomposableDFD(PDF))

scheduled
account file account keep account
travel agency Furthermore, traditional DFD mainly has two types of visual
flight list file accounts bills
representations, which are proposed by Constantine et al. and
Gane et al. [21] respectively. However, there is no obvious
Fig. 1. A example of DFD for booking air ticket system [18].
distinction between these two visualizations, except the rep-
resentation of processes. In our work, the former type from
A. From Traditional DFD to Purified DFD Constantine et al. is selected as the representation of DFDs.
To facilitate understanding of the traditional DFD, an ex-
It is clear that DFD plays a fundamental role in our ample of booking air ticket system [18] is shown in Fig. 1.
microservice-oriented decomposition work. By graphically It displays the four basic elements, whose explanations are
displaying the flow of data within an information system, introduced as follows.
DFD has widely been used as one of the preliminary tools of
• Process Notations (or Operation Notations) refer to
requirement analysis in software engineering. Therefore, here
activities that operate data of the system. An operation
we start from introducing a brief background on traditional
is depicted as a circle with a unique name in form
DFDs, followed by explaining the purified DFD defined in
of verb or verb phrase, for example, “book air ticket”
our study.
and “keep accounts” in Fig. 1. Different from the circle
1) Traditional DFD: From the data’s perspective, a DFD,
type representation from Constantine et al., operations in
which can be generated from business logic of a system,
DFDs defined by Gane et al. are squares with rounded
describes the flow of data through business functions or
corners.
processes. In other words, it illustrates how data is processed
• Data Store Notations represent the repository of data
by a business function or an operation of a system in terms
manipulated by operations, which can be databases or
of inputs and outputs. Four basic elements comprise a DFD,
files (“scheduled flight list” and “account file” in Fig. 1).
namely Process, Data Store, Data Flow and External Entity.
A data store is represented by a rectangle in a DFD with

468
 a name in the form of noun or noun phrase. B. From Purified DFD to Decomposable DFD
• Data Flow Notations are directed lines indicating the As described previously, a purified DFD exactly represents
data from or to an operation. The relevant data sit on the the real information flow driven by the corresponding business
line of a data flow. At least one point of a data flow is logic. A decomposable DFD, as a continuation, condenses the
linked to a circle of operation. precedent purified DFD into a decomposition-friendly dataflow
• External Entity Notations stand for the objects which representation by applying a set of rules (e.g., combining the
are the destinations or sources of data outside the system. same operations with the same type of output data). Note
An example of external entity in Fig. 1 is “travel agency”. that, to reduce possible human mistakes when drawing a
Similar to the representation of data store notation, an decomposable DFD and also to make the drawn decomposable
external entity is also depicted as a closed rectangle in DFD more traceable, the backend purified DFD acts as an
DFDs. irreplaceable bridge between the real-world business logic and
2) Purified DFD: Purified DFD is a more data-focused ver- the corresponding decomposable DFD.
sion against traditional DFD, by excluding the side information To facilitate explaining the rules of generating abstract DFD,
such as data store and external entity from the traditional we use a graph definition to conceptualize the purified DFD in
dataflow representation. As showed in Fig. 2, data in purified advance, as showed in Definition 1. It is also noteworthy that
DFD is represented by rectangles and data flows only indicate the rules have essentially been implemented in the function
the direction of data transmission. Moreover, operations in GetDecomposableDFD(PDF) in Algorithm 1.
purified DFD should be the most fine-grained and regular,
and the regularity check will be introduced in next subsection. D2
Therefore, in the potentially purified DFD, we split up the
coarse-grained process “book air ticket” (cf. Fig. 1) which has
D1 P1 D3 P3
two operations of “flight scheduling” and “cost calculation”.

P2 D4 D7
flight list

D5 P4 D6
booking air flight scheduled ready air
ticket list scheduling flight ticket
Fig. 3. A conceptual graph of the potentially purified DFD.

cost calculation expenditure air tickets Definition 1. A purified DFD is a directed graph G(V, E),
where V is the set of nodes and E is the set of directed
edges showing the flowing directions of data. In particular,
flight list keep accounts account bills V = P ∪ D, where P indicates the processing (operation)
nodes and D denotes the data nodes. As such, we can use
Fig. 2. A example of the potentially purified DFD for booking air ticket conceptual diagrams to significantly simplify the representa-
system.
tion of data flows. For example, given the aforementioned air
ticket booking system, by using P = {P1 , P2 , P3 , P4 } and
As mentioned previously, the construction of a purified D = {D1 , D2 , D3 , D4 , D5 , D6 , D7 } to represent the three
DFD can start from drawing a traditional DFD, and then operations and seven data nodes respectively, the purified DFD
the traditional DFD can gradually be refined by specifying (cf. Fig. 2) can be further redrawn into its conceptual version,
the operation activities and excluding side information (e.g., as illustrated in Fig. 3.
data store and external entities). In particular, the construction Following Definition 1, we draw conceptual diagram pieces
needs to conform to the following two basic rules. to concisely explain three dataflow condensing rules.
• Rule 1. In a purified DFD, operations need to be detailed • Rule 3. When condensing a purified DFD into a decom-
enough to represent all the individual data processing posable DFD, each operation node needs to be adjusted
activities in the original business logic, while the data to have one output data only.
representation related to an operation should keep the • Rule 4. When condensing a purified DFD into a decom-
semantic granularities of input and output data without posable DFD, each data node needs to be adjusted to have
further splits. one type of precedent operation at most.
• Rule 2. In a purified DFD, operations should be norma- Rule 3 and Rule 4 are applied to ensure the regularity of
tive verbs or verb phrases that can reflect the semantic purified DFDs. In Fig. 4 and Fig. 5, we display scenarios
meaning of the corresponding data processing activities, which break these two rules respectively and then provide the
while data should be named using semantically mean- regular construction.
ingful nouns or noun phrases occurred in the original According to Rule 3, each operation only has one output
business logic. data, while data D1 and D2 are all output from operation P

469
in the scenario of Fig. 4. If D1 and D2 are the same to each
D3 P2
other, then they should be merged into data D (cf. Fig. 4a);
P1 D1
otherwise, the operation P should continue to split up into P1 P3
D4
and P2 and output D1 and D2 respectively (cf. Fig. 4b).
D5 P1 D2 P4
D1

P P D1

D2
D3 P2
(濌)澳澳澳澳澳澳澳澳澳澳澳澳澳澳澳澳澳澳澳澳澳澳澳澳澳澳澳澳澳澳澳澳(ĸ) D4 P1 PD1 P3
(a)
D5 P4
D1 P1 D1
Fig. 6. An conceptual representation of Rule 5.
P

D2 P2 D2
An example scenario is shown in Fig. 6 to demonstrate how
(濌)澳澳澳澳澳澳澳澳澳澳澳澳澳澳澳澳澳澳澳澳澳澳澳澳澳澳澳澳澳澳澳澳(ĸ) to apply Rule 5 for a decomposable DFD. After combing the
(b)
same two operations P1 and its output data D1 and D2 , the
initial input data of P1 —D3 , D4 and D5 , are all combined
Fig. 4. An conceptual representation of Rule 3.
into P D1 . Then according to Rule 5, the new output data P D1
On the base of Rule 4, each data needs to be generated should point to the operations—P2 , P3 and P4 into which D1
by only one type of operation, but two operations P1 and P2 and D2 originally input.
output one data D in Fig. 5. In this scenario, P1 and P2 should IV. C ASE S TUDY
be adjusted to one type of operation P , if they are the same
To demonstrate and also validate our microservice-oriented
to each other (cf. Fig. 5a); or data D should continue to be
decomposition mechanism, we conducted a pair of case studies
broken down into D1 and D2 , as shown in Fig. 5b.
by employing two typical business logic modules from a recent
movie-information-crawling project. When it comes to their
P1 P data flows, in particular, each operation has only one input data
in the first case, while multiple input data might be involved
D D in an operation in the second case.
P2 P A. Case Study 1
(濌)澳澳澳澳澳澳澳澳澳澳澳澳澳澳澳澳澳澳澳澳澳澳澳澳澳澳澳澳澳澳澳澳(ĸ) 1) Business Scenario: In the first case, we selected the
business logic scenario in which the details and comments
(a)
of movies are crawled from webpage. To be more specific,
as shown in Fig. 7, the application crawls the movie list by
P1 P1 D1 an initial url first, then extracts the url of each movie in the
list and crawls the webpage, then crawls the comment list for
D
the comment details extraction after extracting the details of a
P2 P2 D2 movie and its comment list url, and at last exports structured
movie and comment details into database.
(濌)澳澳澳澳澳澳澳澳澳澳澳澳澳澳澳澳澳澳澳澳澳澳澳澳澳澳澳澳澳澳澳澳(ĸ) The first case study was performed to formally trail the
(b) microservice-oriented decomposition process by our three-step
Fig. 5. An conceptual representation of Rule 4. mechanism as follows.
2) Constructing a purified DFD: Given the business logic
• Rule 5. When condensing a purified DFD into a de- scenario, we manually constructed a purified and detailed DFD
composable DFD, after applying Rule 3 and 4, the same according to Rule 1 and Rule 2 (see Section III-A2). Recall
operations with the same type of output data need to be that the purified DFD (cf. Fig. 8) excludes the side information
combined into one operation with its output data. Since it such as data store and external entity from the traditional DFD.
is usually difficult to keep the same semantic meaning of On the other hand, every single data processing activity of the
the output data after combination, it would be needed to business logic is displayed in Fig. 8. Based on Rule 1, we kept
name the combined output data with an abstract semantic the original semantic granularity of data as it is, for example,
concept. movie list. Moreover, we denominated operations with three

470
 movie list url

comment (next page)

movie details details crawl

movie list extract

movie list comment list

extract extract
initial movie
list address
(next page)
Fig. 7. The business logic scenario of the first case. movie urls

comment
crawl list url crawl
types of detailed semantic verbs, i.e. crawl, extract and parse,
which represent the corresponding activities in the aforemen-
tioned business logic. We also reserved the semanteme of data movie page extract comment list
and represented them with the form of semantic noun phrases,
for example, movie list urls and comment details.
In particular, the purified DFD in Fig. 8 illustrates the details extract extract
of circularly extracting movie list urls and crawling movie list.
Because movies are usually displayed by multiple pages, the movie details comment details
application crawls movie list using movie list urls of the first
page, then extracts the movie list urls of next page from the
previous movie list page, and crawl the next movie list pages parse parse
iteratively. Similarly, it also needs to iteratively extracting
comment list urls and crawling comment list in the business structured structured
logic of this case. movie details comment details
3) Condensing the purified DFD into a decomposable
Fig. 8. The purified DFD of the first case.
DFD: After constructing the purified DFD, the regularity
should be checked based on Rule 3 and Rule 4 (see Section
III-B) to ensure that each operation node has one output data respectively from movie page and comment list that are
only and each data node has one type of precedent operation the output data of Crawl.
at most. It is clear that our purified DFD conforms these two As for the data, movie list url, comment list url, movie
rules, especially when the data comment list urls is delivered urls, movie details and comment details are all partial
by two operations under the same type. content that we want to extract. In other words, they
To condense the purified DFD into a decomposable DFD, belong to the same type with slight differences in their
we identified and combined the following three operations webpage positions.
with the same type of output data: • Operation 3: Parse. Based on the data movie details

• Operation 1: Crawl. With the input data movie list url, and comment details extracted by the previous operation,
movie urls and comment list url, the operation Crawl Parse occurs twice for the final structured movie details
outputs data movie list, movie page and comment list and structured comment details.
respectively. Both structured movie details and structured comment
The output data of Crawl are the detailed webpage details from Parse are then defined as the same type of
content, which can be obtained by different methods, structured content.
i.e. URL and Ajax. Therefore, according to Rule 5 (see Section III-B), oper-
• Operation 2: Extract. In this case, the operation Extract ations with the same type of output data are combined into
is used six times. Two Extract instances are to iteratively one and their output data are denominated by the type with
extract movie list url and comment list url from the higher-level abstract semanteme (cf. Fig. 9). In particular, the
respective input data movie list and comment list. Two operation combination is implemented automatically by the
instances use the output data of Crawl (i.e. movie list function GetDecomposableDFD(PDF) in Algorithm 1.
and movie page) as the input and then extract the movie 4) Identifying microservice candidates from the decompos-
urls and comment list url. The other two instances are able DFD: Given a decomposable DFD generated from the
performed to extract movie details and comment details purified DFD, we automatically extracted individual operation-

471
 webpage
input such as movie name and time from the user to compose
crawl
content one screening information of a movie. Then it queries different
ticket prices from a database using the screening information
and online box office list. Finally, it integrates the movie
extract
(next page url) details and ticket prices to the final webpage which displays
the information of a movie and its ticketing prices from
(the first movie partial webpage different online box offices.
list page url) content
We conducted the microservice-oriented decomposition pro-
cess by the following three steps:
parse

cinema list
structured
content

extract movie name

Fig. 9. The decomposable DFD of the first case.

cinema name compose movie detail

output-data modules from the decomposable dataflow. These
individual modules indicate the potential microservices that
structured
can be developed independently. time screening info
Finally, three microservice candidates were extracted from
the decomposable DFD, i.e. “crawl + webpage content”, online box
office list query
“extract + partial content” and “parse + structured content”,
which are displayed by dashed boxes in Fig. 9. To facili-
tate recognition, achieve better independence, and reflect the different
ticket prices integrate
reusability of services, we finalized the denomination of three
microservice candidates as:
movie price
• Webpage Crawling comparison summary
• Text Extraction
• Text Structuring
Fig. 11. The purified DFD of the second case.

2) Constructing a purified DFD: We followed the same

B. Case Study 2
way to generate the purified and detailed DFD (Fig. 11) as
used in the first case. We also removed the external data store
movie price and focused on data and operations. We kept the original data
comparison as it is according to the Rule 1, for example, movie name.
webpage
Finally, we denominated operations as four types of detailed
semantic verbs, i.e. extract, query, compose and integrate,
different
movie detail ticket prices from the aforementioned business logic.
Moreover, this case demonstrates a relatively complicated
scenario that one operation contains more than one input, e.g.,
screening the operation compose has three inputs and query has two
plan list
inputs.
3) Condensing the purified DFD into a decomposable
movie name day & time cinema name DFD: Similar to the first case, we firstly use Rule 3 and Rule
4 to check if our purified DFD conforms predefined rules. For
example, although the operation compose has three inputs of
online box data, it has only one output data, which makes it compatible
cinema list
office list with our rules.
Then, we identify the following four types of operations
Fig. 10. The business logic scenario of the second case. from the purified DFD. Note that there is not any same type of
multiple operations in the purified DFD, and thus no operation
1) Business Scenario: In the second case, a business sce- combination happens at this step.
nario in Fig. 10 originates from a movie ticket price compari- • Operation 1: Extract. This operation here has one input
son application, which can compare the prices of movie tickets cinema list and one output cinema name.
at different online box offices. Specifically, the application • Operation 2: Query. This operation uses different input
extracts each cinema from the cinema list and takes the initial information, i.e. structured screening information and

472
 cinema list
One aspect is the decomposition result, while another is the
decomposition procedure. Therefore, we use a set of microser-
vice principles and a comparison against Service Cutter [14]
extract movie name to validate our decomposition mechanism with regard to those
two concerns respectively, followed by a discussion about
some limitations of our work at this current stage.
cinema name compose movie detail

structured A. Verification against a set of Relevant Microservice Princi-

time screening info ples

online box When it comes to microservice principles, both the design-

office list query time features (e.g., coupling between microservices) and the
runtime features (e.g., scalability against changing workloads)
different are crucial for evaluating microservice candidates. Since mi-
ticket prices integrate
croservice implementations are out of the scope of our de-
composition mechanism at this current stage, here we mainly
movie price
comparison summary focus on the design-time microservice principles.
1) Fine grain and focus: “Small” and “autonomous” have
Fig. 12. The decomposable DFD of the second case. been considered to be the most important characteristics of
microservices [22]. Each microservice is supposed to “do
one thing well” [23] to fulfill a focused business responsi-
online box office list, to query different ticket prices from
bility only. By emphasizing specific data processing activities
any given data source.
(instead of line of codes or function points), our dataflow-
• Operation 3: Compose. This seems to be the most
driven mechanism guarantees the most fine-grained microser-
complicated operation which has three input data: movie
vice candidates in terms of data operation within a business
name, cinema name and time. However, it has only one
logic. Although small is not necessarily equal to “appropriate”
output data: structured screening information, and thus
especially when taking into account non-functional trade-offs,
we can keep it as it is.
the most fine-grained candidates supply a fundamental ground
• Operation 4: Integrate. This operation integrates differ-
to facilitate further adjusting microservice granularities.
ent ticket prices and movie detail to construct the outcome
webpage movie ticket prices comparison summary. 2) High cohesion and loose coupling: As a principle for
In particular, we claim that the operations Compose and individual microservices, high cohesion requires every single
Integration cannot be combined together because they take microservice to implement a relatively independent piece
different responsibilities: the former combines single condi- of business logic. In contrast, loose coupling is a crucial
tions to a structured key used in database queries, while the principle for involving multiple microservices, which requires
latter integrates multiple elements into one whole summary the involved microservices to depend barely on each other.
webpage without necessarily being structured. Recall that our mechanism extracts “operation and its output
4) Identifying microservice candidates from the decom- data” modules from a decomposable DFD into microservice
posable DFD: Finally, following the same way as shown candidates. By excluding the constraints of input data, each
in the first case, we extract four microservice candidates: “operation and its output data” module essentially emphasizes
“extract + cinema name”, “compose + structured screening its own data processing and does not need to know anything
info”, “query + different ticket prices” and “integrate + movie about its precedent and subsequent operations. For example,
price comparison summary” which are displayed by dashed in the previous Case 1, the intermediate microservice Text
boxes in Fig. 12. To better understand the meaning of these Extraction can accept various text sources besides the webpage
microservices, we renamed them as: content, and it cares little about where its output data will go.
• Text Extraction 3) Neutral development technology: Based on the above-
• Database Query mentioned principles particularly high cohesion and loose cou-
• Structure Composition pling, microservices have been claimed to be developable as
• Text Integration individual applications with their own delivery pipelines. Al-
It is noteworthy that, among the above four microservice though implementing microservices is out of the scope of this
candidates, “Text Extraction” is essentially a reusable one from study, there is no doubt that our decomposed microservices are
the first case study. able to be realized independently with different programming
languages, technologies and even deployment environments.
V. E VALUATION AND L IMITATION D ISCUSSIONS Driven by data flows, our decomposition mechanism enables
We are concerned with two aspects of microservice-oriented the candidate microservices to be logically connected through
decomposition for evaluating a decomposition mechanism. technology-independent data only.

473
 combining the same types of data processing activities). In
fact, it has been reported that small modularity is one of the
keys to reusing a microservice [24]. For case 2, Service Cutter
breaks the system into four candidate microservices, which
seems reasonable. However, Service B and Service D contain
only one or a part of entities. They could have been over cut for
being microservice candidates. Moreover, we should not break
the entity Time into two microservices, because Time.date and
Time.timeOfDay need to stay together to represent a concrete
time.
2) More objective: Service Cutter draws many subjective
Fig. 13. Decomposition results by Service Cutter for the first case. prerequisites into its decomposition. First, Service Cutter
relies on the criteria they define to subjectively determine
the characteristics of each entity, and then they also use the
subjective way to score the weight of dependency graph, which
may lead to inaccurate description of the relationship between
potential microservices. On the contrary, our approach is more
objective, for it is on the basis of DFD which strictly describes
the real business logic and its data flow without incorporating
many subjective concerns.
3) Easier to operate: Our dataflow-driven mechanism is
based on the purified and detailed DFD that is easy to build
from the data flow of a real-world business logic. Differently,
Service Cutter utilizes Entity Relation Model and many other
complex criteria which make the modeling process more
complex and not intuitionistic.
4) Easier to understand: Our approach returns the de-
composition microservices with the style of “operations +
its output data”, which is clear and straightforward. More
importantly, by largely inheriting relevant semantic meanings
from the original data flow, our decomposition mechanism can
Fig. 14. Decomposition results by Service Cutter for the second case.
conveniently generate lightweight descriptions for the resulting
microservices [25]. On the contrary, from Service Cutter’s
B. Comparison to Service Cutter result, it is difficult to understand the content of microservices
or know how to design them, particularly with data from
For further evaluation, we also select a decomposition pro-
different entities binding together.
totype for microservice identification, i.e. Service Cutter [14],
and compare its decomposition results with ours. We select C. Limitations
Service Cutter because it is also a semi-automated mechanism Despite the aforementioned advantages, our dataflow-driven
and is accessible online. The other related studies (cf. Section approach to microservice-oriented decomposition still suffers
II-A) are either manual strategies or closed sources. Therefore, from several limitations at this current stage.
Service Cutter seems to be the most conveniently comparable
Firstly, identifying the same data operations requires exper-
opponent against our decomposition mechanism.
tise to some extent. Currently, the combination of the same
According to Service Cutter’s input requirements and rep- operations in the purified DFD is based on the operation
resentation criteria, we adjusted the input formats of our case names. Therefore, it is crucial to denominate operations with
studies, and using Service Cutter to obtain the decomposition suitable semanteme. However, different practitioners might
results, as shown in Fig. 13 and Fig. 14.1 In comparison have different naming conventions. To reduce the possible
with Service Cutter’s decomposition, our approach shows chaos in naming data operations, a potential solution is to
superiorities in the following aspects. define and supply a set of standard operations in advance for
1) More rational: For case 1, Service Cutter only gives drawing purified DFD. Inspired by the basic CRUD operations
one candidate microservice, which would not be fine-grained in database, since we are concerned with the most fine-
enough and reusability-friendly. In contrast, the reusability of grained operation activities, there could exist limited common
our operation-focused microservice candidates have inherently operations in generic data flows.
been improved since drawing the decomposable DFDs (i.e. Secondly, candidate microservices obtained from our de-
1 The E-R diagrams and JSON-format input data for using Service Cutter composition mechanism could still need expert judgement
in our two case studies are shared online: https://goo.gl/ooo6vo before being developed in practice. As mentioned previously,

474
our mechanism provides the most fine-grained microservice R EFERENCES
candidates in terms of data operation within a business logic. [1] C. Richardson, “Pattern: Monolithic architecture,” 22 June 2017.
Unlike Service Cutter, we treat those various predefined crite- [Online]. Available: http://microservices.io/patterns/monolithic.html
ria to be post-decomposition considerations for adjusting mi- [2] M. Fowler and J. Lewis, “Microservices,” 10 June 2014. [Online].
Available: https://martinfowler.com/articles/microservices.html
croservice granularities. In other words, given more concerns [3] S. Newman, Building microservices, 2nd ed. Sebastopol, California:
other than data and operation, some candidates might need O’Reilly Media, Inc., 27 February 2015.
to be integrated into relatively coarse-grained microservices [4] O. Zimmermann, “Microservices tenets agile approach to service devel-
at design time. However, by employing our decomposition opment and deployment,” Comput. Sci. Res. Dev., vol. 32, no. 3, pp.
301–310, July 2017.
mechanism, we believe that at least practitioners do not have [5] P. D. Francesco, I. Malavolta, and P. Lago, “Research on architecting
to worry about further decomposing the generated candidate microservices: Trends, focus, and potential for industrial adoption,” in
microservices. Proc. ICSA 2017. IEEE, April 2017, pp. 21–30.
Thirdly, our microservice-oriented decompostion mecha- [6] N. Alshuqayran, N. Ali, and R. Evans, “A systematic mapping study
in microservice architecture,” in Proc. SOCA 2016. IEEE, November
nism has not been widely applied to large-scale projects 2016, pp. 44–51.
yet. As a result, the comparison between Service Cutter and [7] C. Richardson, “Introduction to microservices,” 9 May 2015. [Online].
our mechanism is mainly from the perspective of ourselves. Available: https://www.nginx.com/blog/introduction-to-microservices/
[8] G. Kecskemeti, A. C. Marosi, and A. Kertesz, “The ENTICE approach
Furthermore, since our proposed mechanism is for design-time to decompose monolithic services into microservices,” in Proc. HPCS
decomposition, there is still a lack of evaluation w.r.t. run- 2016. IEEE, July 2016, pp. 591–596.
time features of candidate microservices (e.g., non-functional [9] M. L. Abbott and M. T. Fisher, The Art of Scalability: Scalable Web
requirements like microservices’ scalability against changing Architecture, Processes, and Organizations for the Modern Enterprise,
1st ed. Boston, Massachusetts: Addison-Wesley Professional, December
workloads). To eliminate this limitation, we are currently 2009.
trying to introduce our decomposition mechanism to several [10] C. Richardson, “Pattern: Microservice architecture,” 22 June 2017.
ongoing projects with microservice implementations. As such, [Online]. Available: http://microservices.io/patterns/microservices.html
we will be able to gradually incorporate practical feedback into [11] E. Evans, Structured Design: Fundamentals of a Discipline of Computer
Program and Systems Design. Boston, MA, USA: Addison-Wesley
our future work to reinforce the evaluation. Longman Publishing Co., Inc., 2002.
[12] T. Vresk and I. Čavrak, “Architecture of an interoperable IoT platform
VI. C ONCLUSION based on microservices,” in Proc. MIPRO 2016. IEEE, May 2016, pp.
1196–1201.
In order to address the challenges in migrating monolith to
[13] S. Hassan, N. Ali, and R. Bahsoon, “Microservice ambients: An archi-
microservices architecture, we proposed a top-down decom- tectural meta-modelling approach for microservice granularity,” in Proc.
position approach driven by data flows of business logic. The ICSA 2017. IEEE, April 2017, pp. 1–10.
microservice-oriented decomposition process can be break into [14] M. Gysel, L. Kölbener, W. Giersche, and O. Zimmermann, “Service
Cutter: A systematic approach to service decomposition,” in Proc.
three phases: First, a purified and detailed DFD is constructed ESOCC 2016. Springer, September 2016, pp. 185–200.
from business logic on the basis of requirement analysis. Sec- [15] F. Mardukhi, N. NematBakhsh, K. Zamanifar, and A. Barati, “QoS
ond, the purified DFD is automatically condensed into a de- decomposition for service composition using genetic algorithm,” Appl.
Soft Comput., vol. 13, no. 7, pp. 3409–3421, February 2013.
composable DFD in which the same operations with the same
[16] S. X. Sun and J. Zhao, “A decomposition-based approach for service
type of output data are combined together. Last, microservice composition with global QoS guarantees,” Inf. Sci., vol. 199, pp. 138–
candidates are identified and extracted from the decomposable 153, March 2012.
DFD with the description style of “operation + its output [17] E. Yourdon and L. L. Constantine, Structured Design: Fundamentals of
a Discipline of Computer Program and Systems Design, 1st ed. New
data”. By using two case studies to evaluate our microservice- Jersey, USA: Prentice-Hall, Inc., 1979.
oriented decomposition mechanism, we show that both the [18] Y. Zhao, H. Si, and Y. Ni, “A Service-Oriented analysis and design
decomposition results and the decomposition processes are approach based on data flow diagram,” in Proc. CiSE 2009. IEEE,
relatively rational, objective, and easy-to-understand. December 2009, pp. 1–5.
[19] M. Adler, “A decomposition-based approach for service composition
Considering that our work currently focuses on the de- with global QoS guarantees,” IEEE Trans. Softw. Eng., vol. 14, no. 2,
sign time of microservice-oriented decomposition and cor- pp. 169–183, February 1988.
respondingly there are still limitations, we will unfold our [20] T. Arndt and A. Guercio, “Decomposition of data flow diagrams,” in
future work along three directions. Firstly, we will develop Proc. SEKE 1992. IEEE, June 1992, pp. 560–566.
[21] C. Gane and T. Sarson, Structured Systems Analysis: Tools and Tech-
more objective means to constrain the naming convention of niques. McDonnell Douglas Systems Integration Company, 1977.
data operations. Secondly, we will take into account post- [22] D. Jaramillo, D. V. Nguyen, and R. Smart, “Leveraging microservices
decomposition criteria to help refine the initially generated architecture by using Docker technology,” in Proc. SoutheastCon 2016.
IEEE, March 2016, pp. 1–5.
microservice candidates. Thirdly, we will attend practical
[23] D. Malavalli and S. Sathappan, “Scalable microservice based archi-
projects with microservice implementations, so as to further tecture for enabling DMTF profiles,” in Proc. CNSM 2015. IEEE,
validate our decomposition mechanism by investigating the November 2015, pp. 428–432.
runtime performance of the predesigned microservices. [24] T. Schneider, “Achieving cloud scalability with microservices and de-
vops in the connected car domain,” in Proc. Soft. Eng. 2016. CEUR-
ACKNOWLEDGMENT WS.org, 23-26 February 2016, pp. 138–141.
[25] J. I. Fernández-Villamor, C. Á. Iglesias, and M. Garijo, “Microservices
This work is supported by the National Natural Science - lightweight service descriptions for REST architectural style,” in Proc.
Foundation of China (Grant No.61572251). ICAART 2010. INSTICC, January 2010, pp. 576–579.

475