Domain-Driven Service Design

Kapferer, Stefan; Zimmermann, Olaf

doi:10.1007/978-3-030-64846-6_11

Cited by 23 publications

(11 citation statements)

References 15 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…When considering domain- and model-driven approaches (questions Q18 and Q19), 16 publications consider domain-driven approaches and 26 consider model-driven ones, such as Kapferer & Zimmermann (2020) , Avritzer et al (2020) . These topics are therefore not as widespread as DevOps.…”

Section: Review Resultsmentioning

confidence: 99%

Microservice security: a systematic literature review

Berardi

Giallorenzo

Mauro

et al. 2022

PeerJ Computer Science

View full text Add to dashboard Cite

Microservices is an emerging paradigm for developing distributed systems. With their widespread adoption, more and more work investigated the relation between microservices and security. Alas, the literature on this subject does not form a well-defined corpus: it is spread over many venues and composed of contributions mainly addressing specific scenarios or needs. In this work, we conduct a systematic review of the field, gathering 290 relevant publications—at the time of writing, the largest curated dataset on the topic. We analyse our dataset along two lines: (a) quantitatively, through publication metadata, which allows us to chart publication outlets, communities, approaches, and tackled issues; (b) qualitatively, through 20 research questions used to provide an aggregated overview of the literature and to spot gaps left open. We summarise our analyses in the conclusion in the form of a call for action to address the main open challenges.

show abstract

Section: Review Resultsmentioning

confidence: 99%

Microservice security: a systematic literature review

Berardi

Giallorenzo

Mauro

et al. 2022

PeerJ Computer Science

View full text Add to dashboard Cite

show abstract

“…Microservice Domain-Specific Language (MDSL) [10] is an emerging abstract service contract language that exposes the Microservice API (MAP) patterns used above as decorators. As an example, let us model the example from Section 2 in MDSL (including the data contracts specifying request parameters and response representations, as well as error reports): API description ApactaAPI version "v1" overview "See previous paper sections and APIs.guru" data type CityCollection { "data":City*, "pagination":PaginationDetails, "success":Metadata<bool>} data type City { "created":Metadata<string>, "deleted":Metadata<string>, "id":ID<string>, "modified":Metadata<string>, "name":Data<string>, "zipCode":Data<int>} data type PaginationDetails { "count":Metadata<int>, "current_page":ID<string>, "has_next_page":Metadata<bool>, "has_prev_page":Metadata<bool>, "limit": Metadata<int>, "page_count":Metadata<int>} data type ErrorNotFound { "data": { "code":Data<int>, "message":Data<string>, "url":Link}, "success":Metadata<bool>} endpoint type CityEndpoint serves as REFERENCE_DATA_HOLDER and COLLECTION_RESOURCE exposes operation getListOfCities with responsibility RETRIEVAL_OPERATION expecting payload "zipCode":Data<string>?…”

Section: Apis With Fragmentmentioning

confidence: 99%

“…The above specification snippets merely demonstrate that it is feasible to model HTTP resource APIs in MDSL and to leverage the primitive names from previous sections as well as MAP decorators while doing so. A thorough introduction to MDSL can be found in [10], and the language reference is available at https://microserviceapi-patterns.github.io/MDSL-Specification.…”

Section: Apis With Fragmentmentioning

confidence: 99%

“…(1) Close an existing position (2) Delete Link-Will not delete the target object (3) Delete a contact device for a user Delete a contact device for a user (4) Deletes the given device, and invalidates any access token assoicated with it (5) Delete a directory tenant under a resource group (6) Delete a node-Remove the node identified by id A node can only be deleted if it is currently offline (7) Delete a node-Remove the node identified by id A node can only be deleted if it is currently offline and does not host any master deployments (8) Delete file-Delete file uploaded to a project from wall post or form (9) Delete maintenance configuration (10) This primitive is less frequently used. The intersection between the labels used with the "Remove All" variant and the two smells is rather small, resulting in the two labels: secrets and tags.…”

mentioning

confidence: 99%

See 1 more Smart Citation

From OpenAPI Fragments to API Pattern Primitives and Design Smells

Serbout

Pautasso

Zdun

et al. 2021

26th European Conference on Pattern Languages of Programs

Self Cite

View full text Add to dashboard Cite

In the past few years, the OpenAPI Specification (OAS) has emerged as a standard description language for accurately modeling Web APIs. Today, thousands of OpenAPI descriptions can be found by mining open source repositories. In this paper, we attempt to exploit these artifacts to extract commonly occurring building blocks used in Web API structures, in order to assist Web API designers in their modelling task. Our work is based on a fragmentation mechanism, that starts from OpenAPI descriptions of Web APIs to extract their structures, then fragment these structures into smaller blocks. This approach enabled us to extract a large dataset of reoccurring fragments from a collection of 6619 API specifications. Such fragments have been found multiple times in the same or across different APIs. We have classified the most reoccurring fragments into four pattern primitives used to expose in the API access to collections of items. We distinguish for each primitive variants from design smells. This classification is based on the specific combinations of operations associated with the collection items and on an in-depth analysis of their natural language labels and descriptions. The resulting pattern primitives are intended to support designers who would like to introduce one or more collections for a specific class of items in their HTTP-based API. CCS CONCEPTS• Software and its engineering → Patterns; Designing software.

show abstract

“…On the side of design, Model-Driven Engineering (MDE) [15] has become a prominent methodology for the specification of service architectures [2]. Frameworks such as LEMMA, MicroBuilder, and MDSL offer modelling languages to design service components that abstract from concrete implementations [30,31,19].…”

Section: Introductionmentioning

confidence: 99%

Jolie & LEMMA: Model-Driven Engineering and Programming Languages Meet on Microservices

Giallorenzo,

Montesi,

Peressotti

et al. 2021

Preprint

View full text Add to dashboard Cite

In the field of microservices, Model-Driven Engineering (MDE) has emerged as a powerful methodology for architectural design. Independently, the community of programming languages has investigated new linguistic abstractions for effective microservice development. Here, we present the first preliminary study of how the two approaches can cross-pollinate, taking the LEMMA framework and the Jolie programming language as respective representatives. We establish a common ground for comparing the two technologies in terms of metamodels, discuss practical enhancements that can be derived from the comparison, and present some directions for future work that arise from our new viewpoint.

show abstract

Domain-Driven Service Design

Cited by 23 publications

References 15 publications

Microservice security: a systematic literature review

Microservice security: a systematic literature review

From OpenAPI Fragments to API Pattern Primitives and Design Smells

Jolie & LEMMA: Model-Driven Engineering and Programming Languages Meet on Microservices

Contact Info

Product

Resources

About