Citation: da Silva, C.E.; Gomes, E.L.;
Basu, S. BPM2DDD: A Systematic
Process for Identifying Domains from
Business Processes Models. Software
2022, 1, 417–449. https://doi.org/
10.3390/software1040018
Academic Editors: Sanjay Misra,
Robertas Damaševiˇcius and
Bharti Suri
Received: 28 July 2022
Accepted: 24 September 2022
Published: 29 September 2022
Publisher’s Note: MDPI stays neutral
with regard to jurisdictional claims in
published maps and institutional affil-
iations.
Copyright: © 2022 by the authors.
Licensee MDPI, Basel, Switzerland.
This article is an open access article
distributed under the terms and
conditions of the Creative Commons
Attribution (CC BY) license (https://
creativecommons.org/licenses/by/
4.0/).
Article
BPM2DDD: A Systematic Process for Identifying Domains
from Business Processes Models
Carlos Eduardo da Silva
1,∗
, Eduardo Luiz Gomes
2
and Soumya Sankar Basu
1
1
Department of Computing, Sheffield Hallam University, Sheffield S1 2NU, UK
2
E-Masters Tecnologia, Natal 59151-600, Brazil
* Correspondence: c.dasilva@shu.ac.uk
Abstract:
Domain-driven design is one of the most used approaches for identifying microservice ar-
chitectures, which should be built around business capabilities. There are a number of documentation
with principles and patterns for its application. However, despite its increasing use there is still a lack
of systematic approaches for creating the context maps that will be used to design the microservices.
This article presents BPM2DDD, a systematic approach for identification of bounded contexts and
their relationships based on the analysis of business processes models, which provide a business view
of an organisation. We present an example of its application in a real business process, which has also
be used to perform a comparative application with external analysts. The technique has been applied
to a real project in the department of transport of a Brazilian state capital, and has been incorporated
into the software development process employed by them to develop their new system.
Keywords:
domain-driven design; business process management; context map; bounded context
identification
1. Introduction
Domain-Driven Design (DDD) is an approach to develop complex systems from the
early 2000’s. It consists in a series of design patterns and general guidance on their appli-
cation, where the implementation is deeply connected to models that represent the main
business or domain concepts [
1
]. DDD has gained a renewed interest with the appear-
ance of microservice architecture (MSA) [
2
]. Microservices can be currently interpreted as
an implementation tactic of a service oriented architecture, where software systems are
composed by several small services, each running individually in its own process and
communicating with each other through lightweight mechanisms [3].
There is a consensus in the literature (e.g., [
3
–
7
]) that microservices should be built
and maintained around a specific business capability. However, one of the great challenges
of MSA is the decomposition of the system into services properly aligned to the business
context [
4
]. Amiri [
6
] identifies this challenge as the Microservices Identification Problem.
A number of studies explored this problem, for example, systematic literature reviews [
8
]
and interviews and surveys with industry practitioners [
9
,
10
], and have identified that “a
combination of domain-driven design and business capability is the most used strategy to decompose
an application into microservices” [11].
One of the main concepts of DDD is the bounded context. According to Evans &
Fowler [
1
] a “bounded context” is the limited application of a specific domain model.
The use of bounded contexts to define structured interfaces around the boundaries of the
business domain favours the definition of loosely coupled and highly cohesive services [
5
],
being highly recommended and explored for the definition of microservices. However,
the use of DDD is a complex activity in which the results obtained often depends on
the level of experience of the development team [
12
] This is further demonstrated by the
existence of approaches to help in the use of incomplete DDD artefacts [2].
Software 2022, 1, 417–449. https://doi.org/10.3390/software1040018 https://www.mdpi.com/journal/software
