ID Primary study,Limitation Name,System Type / Proposal,Activity,Extraction,Comments
PS2,Procedure not defined,Example system,Migration," - The disadvantages are that there is no strict technically defined process for defining bounded contexts. The procedure may not be applicable to some types of software that work on specialized software.  (Ivanov, N., & Tasheva, A. (2021). A Hot Decomposition Procedure, P. 5: 2954)
",None
PS4,Lack of trazability,Example system,Development," - some API resources it is unclear on which domain model elements they are based (Singjai, A., & Zdun, U. (2022). Conformance Assessment of Archi, P. 4: 972)",Key system: BAS
PS4,Lack of trazability,Example system,Development," - For some API resources it is unclear on which domain model elements they are based (Singjai, A., & Zdun, U. (2022). Conformance Assessment of Archi, P. 4: 2054)
",Key system: ESCS
PS5,Lack of trazability,Example system,Development," - the application of DDD for microservice decomposition is perceived to be complex [6]. First, there exist several approaches for deriving microservices from domain models [7]. This situation is fostered by the semantic gap between domain models, which leverage building blocks like Bounded Contexts, classes, and associations, and microservice architectures, which rely on services, interfaces, and message exchange. (Rademacher, F., Sachweh, S., & Zundorf, A. (2020). Deriving Mic, P. 1: 3908)
",None
PS5,Procedure not defined,Example system,Development," - upfront identification of the most appropriate microservice granularities based on Bounded Contexts usually requires experimentation [9]. Consequently, domain models are degraded to sheer documentation artifacts and “implementation templates” [2]. (Rademacher, F., Sachweh, S., & Zundorf, A. (2020). Deriving Mic, P. 1: 3908)
",None
PS5,Procedure not defined,Example system,Development," - However, still manual adaptations may be required to resolve underspecification upon which transformations cannot decide objectively (cf. Subsect. IV-B). In addition, technology mapping models need to be created manually (cf. Subsect. III-D). (Rademacher, F., Sachweh, S., & Zundorf, A. (2020). Deriving Mic, P. 7: 2106)
",None
PS5,Not enouigh technical details,Example system,Development," - domain models are usually left underspecified to enable quick model sketching and focusing on domain instead of technical issues [7]. By contrast, the implementation of domain models requires unambiguous technical specification and is prone to errors when done manually [8]. (Rademacher, F., Sachweh, S., & Zundorf, A. (2020). Deriving Mic, P. 1: 3908)
",None
PS7,Inconsistency,Proposal,Proposal," - In the traditional way, developers abstract the attribute and extended information into data model, and realize the function as the method of logic layer, so the model and database are basically the same structure. However, in the design scheme based on domain model, the business is regarded as the object of model analysis, so the attribute of mechanism is regarded as the data model of domain model, and the function is regarded as the behavior and interface of domain model. Therefore, it will be found that in this scenario, the domain model and the database model are usually inconsistent. (Ding, Y., Wang, L., Li, S., Wang, X., & Zhang, J. (2020). Enter, P. 4: 3922)
",None
PS9,High coupling,Industry system,Migration," - We continued the investigation of the asynchronous solution to the Payment problem as shown in Figure 4(a). The goal was to achieve decoupling via asynchronous communication between the Customer and Gaming services and the Payment service. Since the current definition of the service boundaries via bounded contexts lead to tight coupling of the three mentioned services when it comes to buying a product of the lottery application, we needed to redraw these boundaries (Krause, A., Zirkelbach, C., Hasselbring, W., Lenga, S., & Kroge, P. 5: 2122)
",None
PS17,Not enough detail,Proposal,Proposal," - In practice, we can see this quite often with so-called anemic domain models [20], an anti-pattern where the domain logic is not kept within the domain model but implemented in the application service layer. In this case, domain objects become merely containers for keeping data, and domain operations become stateless CRUD (create, update, delete) operations that blindly update all attributes of a domain object to some pre-defined state that is passed in as operation parameter (Braun, S., Bieniusa, A., & Elberzhager, F. (2021, April 26). Ad, P. 7: 1234)
",None
PS20,Procedure not defined,Industry system,Development," - DDD primarily builds from a domain model divided into several subdomains (bounding contexts) and aggregate roots. The ‘art’ is to identify an appropriate grouping (Oukes, P., Andel, M. van, Folmer, E., Bennett, R., & Lemmen, C., P. 7: 1551)
",None