BPM2DDD: A Systematic Process for Identifying Domains from Business Processes Models
2. Background and Related Work
2.1. Background on BPM and DDD
- Events: Represents something that happens during the course of a process. Events usually have a cause (trigger) or an outcome. Represented by a circle, there are three basic types of events, namely: start event, intermediate event and end event.
- Activities: Represents a job to be performed within the process flow. An activity can be a task or a sub-process (set of tasks).
- Gateways: Represents a divergence or a convergence of sequence flows in a process. A gateway determines a branching, forking, merging and joining of paths.
- Sequence flows: Demonstrates the order in which activities are performed within a process.
- Message flow: Demonstrates communication between two process participants (represented by two separate pools in a collaboration diagram).
- Pool: Represents a participant in a collaboration. It acts as a container partitioning a set of activities from other pools.
- Lane: Represents a sub-partition of of a pool and serves to organise and categorise activities.
- Messages: Represents the content of a communication between two participants.
- Data objects: Represent a set or collection of information. Data objects can serve as input or be produced in process activities.
- Groups: Represents a grouping of elements within the same category. Groups are typically used for documentation and analysis purposes and do not change the flow of the process.
- Partnership: Teams define a process to plan, develop and manage the integration between systems. They cooperate with each other in the evolution and maintenance of the interfaces of both systems.
- Customer-Supplier Development: The upstream team (supplier) can be successful independent of the downstream team (customer). The needs of Downstream team are handled in various ways with consequences. However, the priorities of the downstream team are considered in the planning of the upstream team.
- Conformist: The upstream team has no motivation to meet the needs of the downstream team. The translation complexity between the bounded contexts is eliminated and the downstream team faithfully adheres to the upstream team model.
- Open Host Service: Defines a protocol for accessing subsystems as a set of services. Make the protocol explicit/public so that everyone who needs it can integrate into the system. The protocol can be improved and expanded when new requirements arise, except when a single team has an unusual need.
- Published Language: Translating communication between models from two linked contexts requires a common language. A well-documented shared language must be maintained to express domain information necessary for communication.
- Core: Represents the main contexts or core of the business. It is usually linked to the organisation’s purpose activities.
- Support: Represents contexts created to support the core business. They are not usually the organisation’s purpose activities, but they support it.
- Generic: Represents contexts that don’t capture anything special for the business, but are needed for general solution.
2.2. Related Work
3. The BPM2DDD Approach
3.1. Contextualisation and Methodology
3.2. Phase1: Review Input BPMN
- Pools The BPMN model must have at least one pool, which represents a clear organisational boundary like a company. Separate pools should be used for external organisations.
- Lanes Pools must have at least one lane, which represents one actor in the process. An actor is formed by a role (function) plus an organisational unit (e.g., department).
- Systemic actors Automated activities performed by some system should be explicitly modelled with a systemic actor.
- Activities Activities should represent a job to be performed and always be assigned to a lane.
- Sub-processes and groups: Activities can be grouped together using sub-processes or the BPMN group element.
- Control flow: The control flow (sequence, merge and split gateway) should be explicitly used.
- Events Each process should have explicit start and end events. Each event should have a start event and an end event to denote the completion of the event.
- Communication and message flows Communication between actors should be explicitly modelled with communication events and message flows. Message flows should be used to communicate between pools.
- Data objects Data objects and data stores should be explicitly used to represent documents, artefacts or information flow throughout the process.
- Does the business process model actually mirror the operational reality?
- Are there pools or lanes that demonstrate which actors are involved in the process?
- Do the actors make their role and organisational unit of origin explicit?
- If there are external actors, are they allocated in separate pools/lanes?
- If any, are automated activities allocated to systemic actors?
- If any, are related activities grouped into BPMN sub-processes or groups?
- If any, are communications explicit in the model through communication events and message flows?
- If any, are there data objects that demonstrate the sharing of information between process activities?
3.3. Phase2: Build Context Map
3.3.1. Identify Bounded Contexts and Subdomains
- What is the role or responsibility of organisational unit of actor B in the business context under consideration?
- What is the objective of each activity performed by actor B?
- Is the result produced by the activities of an actor B of interest, direct dependence or acceptance criteria for the organisational unit of actor A to fulfil its role, achieve its objective or perform some activity? Yes or No.
- Does the result produced by the activities of actor B modify the state of some BPMN data object used by actor A? Yes or No.
- Approach by activity: Based on the analysis of the objectives and obtained results produced by the activities (or group of activities).
- Approach by organisational unit: Based on the analysis of the objectives or responsibilities of each organisational unit.
3.3.2. Identify Groups of Related Activities
3.3.3. Identify Message Flows and Communication Events
3.3.4. Identify Business Objects
- In what bounded context is the business object created? If an activity is responsible for creating a business object, it is likely that the source of this object is the bounded context to which this activity belongs to.
- How often is this business object used in activities in the same bounded context? If a business object is used by several activities that belong to the same bounded context, it is likely that this object belongs to that context.
- Is the data object’s name, terminology, and meaning closely related to the bounded contexts in which it is used? If when comparing a business object with a bounded context that uses it, their names, terminology, or meanings are close, it is likely that the object belongs to that context.
3.3.5. Identify Relationships
3.3.6. Build Context Map
3.4. Phase3: Review
- Do the domains represent the organisational focus?
- Do the identified subdomains maps with organisational objectives?
- Do bounded contexts represent existing business contexts of the organisation?
- Is the mapping between sub-domains and bounded contexts aligned with organisation business?
- Are business functions implemented as part of a context reflecting the business functions of the organisation?
- Are the relationships between the bounded contexts aligned with the business?
4. Application of the Technique
4.1. Contextualisation of the Example Application
4.2. Phase 1: Review Input BPMN—IRB Process
4.3. Phase 2: Build Context Map—IRB Process
4.3.1. Identify Bounded Contexts and Subdomains—IRB Process
4.3.2. Identify Groups of Related Activities—IRB Process
4.3.3. Identify Message Flows and Communication Events—IRB Process
4.3.4. Identify Business Objects—IRB Process
4.3.5. Identify Relationships—IRB Process
4.3.6. Build Context Map
5. Evaluation and Discussion
5.1. Validation of the Context Map
5.2. A Comparison
- The external participants reported that the activities for direct extraction of information from the business process models with the support artefacts were carried out without difficulties. This indicates that supporting artefacts help appliers to make gradual progress in extracting information about the domain.
- The external participants expressed their difficulties about how to perform some activities. These difficulties could have been reduced if they had a more in-depth knowledge of the BPM2DDD process. This indicates that more time should have been allocated for explaining the approach.
- From the difference between the planned duration and actual time spent in the application, it is obvious that the BPM2DDD process with all its steps can be time consuming. This leads to the need to divide the application into different sessions. This also relates to the previous observation about spending more time in in-depth understanding of the BPM2DDD approach before using,
- The greatest challenge reported is that activities that require domain knowledge demanded more time, even with a domain expert providing information.
- Manual filling in the artefacts by the applicators, can be time consuming, especially if the process model has many elements. This indicates the need for support tools that help applicators to extract information from the BPMN model in an automated way.
- The external participants did not register generic contexts and subdomains such as Document printing. This indicates the need to address such DDD concepts in the explanation of the technique.
- There was a difference between the terms used to describe the bounded contexts and subdomains, where the context of Permits has been identified as Operations or Vehicle Control; and Payments has been identified as Finance.
- The bounded context Vehicle Inspection has been associated with the new sub-domain Inspection instead of the existing subdomain Operations and Permissions. This indicates a lack of more comprehensive knowledge about the organisation.
- Creating services based on the bounded contexts and subdomains identified in the comparative application could lead to building a system not aligned with the business, which could lead to more frequent changes in the software solution.
- The separation of the bounded context Permits, observed in the first application, in Vehicle Control and Operations, observed in the comparative application, could lead to a greater effort to maintain separate representations for the same domain model.
- Failure to discover the generic context of Document printing would lead to a late identification of this service, which could compromise the development flow and project schedule.
5.3. Discussion, Threats and Limitations
Institutional Review Board Statement
Informed Consent Statement
Data Availability Statement
Conflicts of Interest
|BDM||Business Data Model|
|BPM||Business Process Management|
|BPMN||Business Process Model and Notation|
|IRB||Inclusion/Removal of Buses|
- Evans, E.; Fowler, M. Domain-Driven Design: Tackling Complexity in the Heart of Software; Addison-Wesley: Boston, MA, USA, 2004. [Google Scholar]
- Rademacher, F.; Sachweh, S.; Zündorf, A. Deriving Microservice Code from Underspecified Domain Models Using DevOps-Enabled Modeling Languages and Model Transformations. In Proceedings of the 2020 46th Euromicro Conference on Software Engineering and Advanced Applications (SEAA), Portoroz, Slovenia, 26–28 August 2020; pp. 229–236. [Google Scholar] [CrossRef]
- Lewis, J.; Fowler, M. Microservices. 2019. Available online: https://martinfowler.com/articles/microservices.html (accessed on 2 September 2022).
- Alpers, S.; Becker, C.; Oberweis, A.; Schuster, T. Microservice Based Tool Support for Business Process Modelling. In Proceedings of the 2015 IEEE 19th International Enterprise Distributed Object Computing Workshop, Adelaide, Australia, 21–25 September 2015; pp. 71–78. [Google Scholar] [CrossRef]
- Newman, S. Building Microservices: Designing Fine-Grained Systems, 1st ed.; O’Reilly Media: Sebastopol, CA, USA, 2015; p. 280. [Google Scholar]
- Amiri, M.J. Object-Aware Identification of Microservices. In Proceedings of the 2018 IEEE International Conference on Services Computing (SCC), San Francisco, CA, USA, 2–7 July 2018; pp. 253–256. [Google Scholar] [CrossRef]
- Cerny, T.; Donahoo, M.J.; Pechanec, J. Disambiguation and Comparison of SOA, Microservices and Self-Contained Systems. In Proceedings of the International Conference on Research in Adaptive and Convergent Systems RACS ’17, Krakow Poland, 20–23 September 2017; ACM: New York, NY, USA, 2017; pp. 228–235. [Google Scholar] [CrossRef]
- Huergo, R.; Pires, P.; Delicato, F.; Costa, B.; Batista, T. A Systematic Survey of Service Identification Methods. Serv. Oriented Comput. Appl. 2014, 8, 199–219. [Google Scholar] [CrossRef]
- Di Francesco, P.; Lago, P.; Malavolta, I. Migrating Towards Microservice Architectures: An Industrial Survey. In Proceedings of the 2018 IEEE International Conference on Software Architecture (ICSA), Seattle, WA, USA, 30 April–4 May 2018; pp. 2900–2909. [Google Scholar] [CrossRef]
- Singjai, A.; Zdun, U.; Zimmermann, O. Practitioner Views on the Interrelation of Microservice APIs and Domain-Driven Design: A Grey Literature Study Based on Grounded Theory. In Proceedings of the 2021 IEEE 18th International Conference on Software Architecture (ICSA), Stuttgart, Germany, 22–26 March 2021; pp. 25–35. [Google Scholar] [CrossRef]
- Waseem, M.; Liang, P.; Shahin, M.; Di Salle, A.; Márquez, G. Design, Monitoring, and Testing of Microservices Systems: The Practitioners’ Perspective. J. Syst. Softw. 2021, 182, 111061. [Google Scholar] [CrossRef]
- Hippchen, B.; Schneider, M.; Giessler, P.; Abeck, S. Systematic Application of Domain-Driven Design for a Business-Driven Microservice Architecture. Int. J. Adv. Softw. 2019, 12, 343–355. [Google Scholar]
- Millett, S.; Tune, N. Patterns, Principles, and Practices of Domain-Driven Design; Wiley: Hoboken, NJ, USA, 2015. [Google Scholar]
- Richardson, C. Microservices Patterns: With Examples in Java; Manning: Shelter Island, NY, USA, 2019. [Google Scholar]
- Shenglin, L.; Qinghui, R.; Chen, C. Application of DDD Theory in Analysis and Design of Equipment Maintenance System. In Proceedings of the 2019 IEEE Symposium Series on Computational Intelligence (SSCI), Xiamen, China, 6–9 December 2019; pp. 3275–3280. [Google Scholar] [CrossRef]
- da Silva, C.E.; Medeiros, L.; Justino, Y.; Gomes, E. A Box Analogy Technique (BoAT) for Agile-based Modelling of Business Processes. In Proceedings of the 2022 IEEE 30th International Requirements Engineering Conference (RE), Melbourne, Australia, 15–19 August 2022. [Google Scholar]
- Cardoso, E.C.S.; Almeida, J.P.A.; Guizzardi, G. Requirements Engineering Based on Business Process Models: A Case Study. In Proceedings of the 2009 13th Enterprise Distributed Object Computing Conference Workshops, Auckland, New Zealand, 1–4 September 2009; pp. 320–327. [Google Scholar] [CrossRef]
- Unger, A.; Spinola, M.; Pessôa, M. Requirements Engineering Approaches to Derive Enterprise Information Systems from Business Process Management: A Systematic Literature Review. In Requirements Engineering Und Business Process Management (REBPM), Proceedings of the Workshops at Modellierung Braunschweig, Germany, 21 February 2018; Schaefer, I., Cleophas, L., Felderer, M., Eds.; 2018; pp. 261–271. Available online: http://ceur-ws.org/Vol-2060/rebpm6.pdf (accessed on 2 September 2022).
- da Silva, C.E.; Justino, Y.d.L.; Adachi, E. SPReaD: Service-Oriented Process for Reengineering and DevOps. Serv. Oriented Comput. Appl. 2021, 16, 1–16. [Google Scholar] [CrossRef]
- Van Der Aalst, W.M. Business Process Management: A Comprehensive Survey. ISRN Softw. Eng. 2013, 2013, 1–37. [Google Scholar] [CrossRef]
- Dumas, M.; La Rosa, M.; Mendling, J.; Reijers, H.A. Fundamentals of Business Process Management; Springer: Berlin/Heidelberg, Germany, 2018. [Google Scholar] [CrossRef]
- Benedict, T.; Bilodeau, N.; Vitkus, P.; Powell, E.; Morris, D.; Scarsig, M.; Lee, D.; Field, G.; Lohr, T.; Saxena, R.; et al. BPM CBOK Version 3.0: Guide to the Business Process Management Common Body of Knowledge, 3rd ed.; CreateSpace/ABPMP—Association of Business Process Management Professionals: Pensacola, FL, USA, 2013. [Google Scholar]
- OMG. Business Process Model and Notation (BPMN), Version 2.0.2; Technical Report Formal/2013-12-09; Object Management Group: Needham, MA, USA, 2013. [Google Scholar]
- Vernon, V. Implementing Domain-Driven Design; Pearson Education: London, UK, 2013. [Google Scholar]
- Lai, H.; Peng, R.; Ni, Y. A Collaborative Method for Business Process Oriented Requirements Acquisition and Refining. In Proceedings of the 2014 International Conference on Software and System Process, ICSSP, Nanjing, China, 26–28 May 2014; ACM: New York, NY, USA, 2014; pp. 84–93. [Google Scholar] [CrossRef]
- Götz, B.; Schel, D.; Bauer, D.; Henkel, C.; Einberger, P.; Bauernhansl, T. Challenges of Production Microservices. Procedia CIRP 2018, 67, 167–172. [Google Scholar] [CrossRef]
- Costa, I.C.; de Oliveira, J.M.P. GO4SOA: Goal-oriented Modeling for SOA. In Proceedings of the 12th International Conference on Web Information Systems and Technologies—Volume 1: WEBIST, INSTICC, SciTePress, Rome, Italy, 23–25 April 2016; pp. 247–254. [Google Scholar] [CrossRef]
- Amiri, M.J.; Parsa, S.; Lajevardi, A. Multifaceted Service Identification: Process, Requirement and Data. Comput. Sci. Inf. Syst. 2016, 13, 335–358. [Google Scholar] [CrossRef]
- Daoud, M.; el Mezouari, A.; Faci, N.; Benslimane, D.; Maamar, Z.; Fazziki, A. Automatic Microservices Identification from a Set of Business Processes. In Proceedings of the Smart Applications and Data Analysis. SADASC 2020, Communications in Computer and Information Science, Marrakesh, Morocco, 25–26 June 2020; Volume 1207, pp. 299–315. [Google Scholar]
- Landre, E.; Wesenberg, H.; Rønneberg, H. Architectural Improvement by Use of Strategic Level Domain-Driven Design. In Proceedings of the Companion to the 21st ACM SIGPLAN Symposium on Object-Oriented Programming Systems, Languages, and Applications, OOPSLA ’06, Portland, OR, USA, 22–26 October 2006; Association for Computing Machinery: New York, NY, USA, 2006; pp. 809–814. [Google Scholar] [CrossRef]
- Kapferer, S.; Zimmermann, O. Domain-Driven Architecture Modeling and Rapid Prototyping with Context Mapper. In Model-Driven Engineering and Software Development, Proceedings of the 8th International Conference, MODELSWARD 2020, Valletta, Malta, 25–27 February 2020; Hammoudi, S., Pires, L.F., Selić, B., Eds.; Springer International Publishing: Cham, Switzerland, 2021; Volume 1361, pp. 250–272. [Google Scholar] [CrossRef]
- Giallorenzo, S.; Montesi, F.; Peressotti, M.; Rademacher, F. Model-Driven Generation of Microservice Interfaces: From LEMMA Domain Models to Jolie APIs. In Coordination Models and Languages, Proceedings of the 24th IFIP WG 6.1 International Conference, COORDINATION 2022, Lucca, Italy, 13–17 June 2022; ter Beek, M.H., Sirjani, M., Eds.; Springer International Publishing: Cham, Switzerland, 2022; Volume 13271, pp. 223–240. [Google Scholar] [CrossRef]
- Singjai, A.; Zdun, U.; Zimmermann, O.; Pautasso, C. Patterns on Deriving APIs and Their Endpoints from Domain Models. In Proceedings of the 26th European Conference on Pattern Languages of Programs, EuroPLoP’21, Graz, Austria, 7–11 June 2021; Association for Computing Machinery: New York, NY, USA, 2021; pp. 1–15. [Google Scholar] [CrossRef]
- Wesenberg, H.; Landre, E.; Rønneberg, H. Using Domain-Driven Design to Evaluate Commercial off-the-Shelf Software. In Proceedings of the Companion to the 21st ACM SIGPLAN Symposium on Object-oriented Programming Systems, Languages, and Applications, OOPSLA ’06, Portland, OR, USA, 22–26 October 2006; Association for Computing Machinery: New York, NY, USA, 2006; pp. 824–829. [Google Scholar] [CrossRef]
- Cabrera, E.; Cárdenas, P.; Cedillo, P.; Pesántez-Cabrera, P. Towards a Methodology for Creating Internet of Things (IoT) Applications Based on Microservices. In Proceedings of the 2020 IEEE International Conference on Services Computing (SCC), Beijing, China, 7–11 November 2020; pp. 472–474. [Google Scholar] [CrossRef]
- Santos, N.; Pereira, J.; Ferreira, N.; Machado, R.J. Modeling in Agile Software Development: Decomposing Use Cases towards Logical Architecture Design. In Product-Focused Software Process Improvement, Proceedings of the 19th International Conference, PROFES 2018, Wolfsburg, Germany, 28–30 November 2018; Kuhrmann, M., Schneider, K., Pfahl, D., Amasaki, S., Ciolkowski, M., Hebig, R., Tell, P., Klünder, J., Küpper, S., Eds.; Springer International Publishing: Cham, Switzerland, 2018; pp. 396–408. [Google Scholar]
- Santos, N.; Salgado, C.E.; Morais, F.; Melo, M.; Silva, S.; Martins, R.; Pereira, M.; Rodrigues, H.; Machado, R.J.; Ferreira, N.; et al. A Logical Architecture Design Method for Microservices Architectures. In Proceedings of the 13th European Conference on Software Architecture—Volume 2, ECSA ’19, Paris, France, 9–13 September 2019; Association for Computing Machinery: New York, NY, USA, 2019; pp. 145–151. [Google Scholar] [CrossRef]
- Gysel, M.; Kölbener, L.; Giersche, W.; Zimmermann, O. Service Cutter: A Systematic Approach to Service Decomposition. In Service-Oriented and Cloud Computing, Proceedings of the 5th IFIP WG 2.14 European Conference, ESOCC 2016, Vienna, Austria, 5–7 September 2016; Aiello, M., Johnsen, E.B., Dustdar, S., Georgievski, I., Eds.; Springer International Publishing: Cham, Switzerland, 2016; pp. 185–200. [Google Scholar]
- Tyszberowicz, S.; Heinrich, R.; Liu, B.; Liu, Z. Identifying Microservices Using Functional Decomposition. In Dependable Software Engineering. Theories, Tools, and Applications, Proceedings of the 4th International Symposium, SETTA 2018, Beijing, China, 4–6 September 2018; Feng, X., Muller-Olm, M., Yang, Z., Eds.; Springer International Publishing: Cham, Switzerland, 2018; pp. 50–65. [Google Scholar]
- Hippchen, B.; Giessler, P.; Steinegger, R.H.; Schneider, M.; Abeck, S. Designing Microservice-Based Applications by Using a Domain-Driven Design Approach. Int. J. Adv. Softw. 2017, 10, 432–445. [Google Scholar]
- Baresi, L.; Garriga, M.; De Renzis, A. Microservices Identification through Interface Analysis. In Service-Oriented and Cloud Computing, Proceedings of the 6th IFIP WG 2.14 European Conference, ESOCC 2017, Oslo, Norway, 27–29 September 2017; De Paoli, F., Schulte, S., Broch Johnsen, E., Eds.; Springer International Publishing: Cham, Switzerland, 2017; pp. 19–33. [Google Scholar]
- Mazlami, G.; Cito, J.; Leitner, P. Extraction of Microservices from Monolithic Software Architectures. In Proceedings of the 2017 IEEE International Conference on Web Services (ICWS), Honolulu, HI, USA, 25–30 June 2017; pp. 524–531. [Google Scholar] [CrossRef]
- De Alwis, A.A.C.; Barros, A.; Polyvyanyy, A.; Fidge, C. Function-Splitting Heuristics for Discovery of Microservices in Enterprise Systems. In Service-Oriented Computing, Proceedings of the 16th International Conference, ICSOC 2018, Hangzhou, China, 12–15 November 2018; Pahl, C., Vukovic, M., Yin, J., Yu, Q., Eds.; Springer International Publishing: Cham, Switzerland, 2018; pp. 37–53. [Google Scholar]
- Boeije, H. A Purposeful Approach to the Constant Comparative Method in the Analysis of Qualitative Interviews. Qual. Quant. 2002, 36, 391–409. [Google Scholar] [CrossRef]
- Garriga, M. Towards a Taxonomy of Microservices Architectures. In Software Engineering and Formal Methods, Proceedings of the SEFM 2017 Collocated Workshops: DataMod, FAACS, MSE, CoSim-CPS, and FOCLASA, Trento, Italy, 4–5 September 2017; Cerone, A., Roveri, M., Eds.; Springer International Publishing: Cham, Switzerland, 2018; pp. 203–218. [Google Scholar] [CrossRef]
- Staron, M. Action Research in Software Engineering: Theory and Applications, 1st ed.; Springer International Publishing: Cham, Switzerland, 2020. [Google Scholar] [CrossRef]
Publisher’s Note: MDPI stays neutral with regard to jurisdictional claims in published maps and institutional affiliations.
© 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/).
da Silva, C.E.; Gomes, E.L.; Basu, S.S. BPM2DDD: A Systematic Process for Identifying Domains from Business Processes Models. Software 2022, 1, 417-449. https://doi.org/10.3390/software1040018
da Silva CE, Gomes EL, Basu SS. BPM2DDD: A Systematic Process for Identifying Domains from Business Processes Models. Software. 2022; 1(4):417-449. https://doi.org/10.3390/software1040018Chicago/Turabian Style
da Silva, Carlos Eduardo, Eduardo Luiz Gomes, and Soumya Sankar Basu. 2022. "BPM2DDD: A Systematic Process for Identifying Domains from Business Processes Models" Software 1, no. 4: 417-449. https://doi.org/10.3390/software1040018