FOCUS: MICROSERVICES

Challenges of DDD gains additional relevance

because it provides the means for
decomposing domains into con-

Domain-Driven
texts, each clustering coherent
domain concepts. These contexts
correspond to functional microser-

Microservice
vices3 that provide distinct business
capabilities.
However, applying DDD to MSA
poses several challenges concern-

Design ing service deduction from domain

models, modeling of infrastructure
components, and domain model-
ing in autonomous teams. This ar-
ticle discusses these challenges from

A Model-Driven a model-driven perspective and

presents ways to cope with them
based on model-driven development
Perspective (MDD).4

Running Example: The

Florian Rademacher, Jonas Sorgalla, and Sabine Sachweh, Cargo Domain Model
Dortmund University of Applied Sciences and Arts To illustrate the challenges of
domain-driven microservice de-
sign, we use a cargo-related domain
// This article explores several major challenges model5 as a running example. It
of domain-driven microservice design and is depicted in Figure 1a as a UML
class diagram (see the sidebar
presents ways to cope with them based on “Domain-Driven Design as a Mod-
model-driven development. The article also eling Means”). The diagram also
includes the DDD patterns in the
provides an overview of supportive tools form listed in Table 1.
to practically address the challenges. // The domain model comprises
three Bounded Contexts as UML
packages, which denote starting
points for three corresponding
micro­services. It is centered around
the Cargo concept in the eponymous
context. A Cargo holds various Cus-
tomers, distinguished by roles like
“shipper” or “receiver.” This dis-
tinction is modeled as the qualified
DOMAIN-DRIVEN DESIGN (DDD) modeling of domain experts and UML association role on Cargo. Deliv-
is a popular model-driven method- software engineers. ery History keeps track of cargoes’ Han-
ology for capturing domain knowl- Currently, microservice architec- dling Events, possibly involving a Carrier
edge relevant to software design.1 ture (MSA) is maturing as an archi- Movement from a source Location to a
To foster domain understanding and tectural style for distributed software target Location. A Cargo has a goal—
correctness of an emerging design, systems with high requirements i.e., a Delivery Specification with a desti-
DDD emphasizes agile, collaborative for scalability and adaptability. 2 nation Location.

36 I E E E S O F T WA R E | PUBLI S HED BY THE IEEE COMPUTER SO CIE T Y 0 74 0 -74 5 9 / 1 8 / $ 3 3 . 0 0 © 2 0 1 8 I E E E

Authorized licensed use limited to: UNIVERSIDADE FEDERAL DO ESPIRITO SANTO. Downloaded on July 03,2022 at 14:24:48 UTC from IEEE Xplore. Restrictions apply.
 Challenges of Domain-
Driven Microservice DOMAIN-DRIVEN DESIGN
Design
This section elaborates on three AS A MODELING MEANS
major challenges of domain-driven
microservice design, which im- Domain-driven design abstracts domain concepts in models for software design.
pact the deduction of microservices The domain models are typically sketched as UML class diagrams.1 Classes, at-
from underspecified domain mod- tributes, and methods describe domain concepts. Associations express concept
els, the modeling of MSA infra- relationships.
structure components starting from Domain models are usually underspecified; e.g., attributes possibly have no
domain models, and domain model- types, and methods may lack return types.5 Underspecification fosters quick
ing across distributed autonomous notation learning, model sketching, and focusing on relevant domain information.
micro­service teams. From a model-driven-design perspective, however, it is a major challenging factor
of domain-driven microservice design as it introduces model informality.
Deducing Microservices from
Domain Models
To foster focusing on relevant con-
cepts and efficient modeling, domain instances. However, the model does The model in Figure 1a, for exam-
models typically omit information not specify which operations the ple, does not contain components for
mandatory for deducing micro­ service interface contains and how
services and microservice character- they may be invoked for instance re- • infrastructure provisioning—
istics like trieval. Indeed, the Customer Repository e.g., service discoveries or API
provides two operations that could gateways with stable interfaces
• interfaces and operations; be exposed to the Cargo microservice, for external requests—and
• operation parameters and return but neither is clear if both operations • service deployment—e.g.,
types; and are needed, nor do they specify re- containers.
• endpoints, protocols, and mes- turn types. Concrete interface op-
sage formats. erations cannot be unambiguously Additionally, domain expert re-
deduced from the model. quirements affecting technical aspects
Specific information about these An additional problem occurs of the system must be documented
characteristics is mandatory for ser- when a cross-context association separately from the domain model.
vice implementation. For example, between two domain concepts is Such a requirement could be that the
the model in Figure 1a contains the binary without explicit navigabil- Customer microservice needs to be ex-
Customer context without service in- ity specification—e.g., as for Delivery ternally accessible—e.g., for invoicing
terfaces and endpoints. However, Specification and Location in Figure 1a. purposes. This requirement techni-
these characteristics are necessary Without explicit navigability, in- cally impacts the service: It needs to
for implementing the corresponding stances may or may not be permitted be externally discoverable and acces-
microservice. to access instances at the other end sible, probably through an API gate-
In domain models, associations of a UML association. Hence, the way, and deployed to a container that
between concepts of different con- microservice responsible for request- forwards external requests.
texts define exchange relationships ing concept instances to establish the
for concept instances. When a con- association—i.e., Cargo or Location— Autonomous Domain Modeling
text is implemented as a microservice, cannot be unambiguously determined. Due to high service cohesion and
these relationships correspond to low coupling, microservice owner-
service interactions realizing in- Missing Infrastructure Components in ship is typically assigned to exactly
stance exchange. In Figure 1a, a Cargo Domain Models one team. 2 The team is responsible
is associated with Customers. A Customer Domain models intentionally do for its services’ implementation, op-
microservice thus needs to provide not comprise MSA infrastructure eration, and design, including main-
a Cargo microservice with Customer components. tenance of corresponding Bounded

M AY/J U N E 2 0 1 8 | I E E E S O F T WA R E 37
Authorized licensed use limited to: UNIVERSIDADE FEDERAL DO ESPIRITO SANTO. Downloaded on July 03,2022 at 14:24:48 UTC from IEEE Xplore. Restrictions apply.
 FOCUS: MICROSERVICES

«BoundedContext»
Cargo
«AggregateRoot, handled «Entity»
«Repository» «Entity»
* *
Cargo Repository Entity» «Entity» Handling Event * 0..1 Carrier
role Cargo «ValueObject» {aggregateRoot=Cargo} Movement
find by Tracking ID(String) goal * completion time
find by Customer ID(String) tracking ID {aggregateRoot=Cargo} Delivery History type schedule ID
* Delivery Specification
arrival time

«BoundedContext» «BoundedContext» from to

Customer Location

«Repository» * «Entity» destination «Entity» «Service»

Customer Repository Customer Location * Location Service
find by name(String) name port code resolve by port code(String)
find by Customer ID(String) customer ID

(a)

«Request» «Request»
«Microservice» CustomerAccess ~CustomerAccess «Microservice» ~LocationAccess LocationAccess «Microservice»
Customer Cargo Location

«Service» CustomerAccess LocationAccess «Service»

«Interface» CustomerShared «Interface» LocationShared

CustomerAccess name : String LocationAccess portCode : String
+ findByName(customerName : String) : CustomerShared id : String + resolveByPortCode(portCode : String) : LocationShared
+ findByCustomerId(customerId : String) : CustomerShared

MSA stereotype definitions

MSA stereotype Specializes Semantics
«Microservice» «SoaML::Participant» The annotated component is a microservice that provides and consumes interfaces.

(b)

«MicroserviceArtifact»
«Container» location-microservice.jar
«REST with JSON»
«Node» «APIGateway» * Location
* {URI = /locations/}
Client ClientAPI
* «Execution Environment» «deploy»
{Version = Zuul}
Docker
«MicroserviceArtifact» {Image = ewolff/docker-java}
customer-microservice.jar
{URI = /customers/} * *
«REST with JSON»
«Container» «ServiceDiscovery» * *
Customer Discovery «MicroserviceArtifact»
*
{Version = Eureka} «Container» cargo-microservice.jar
«Execution Environment» *
«deploy» Cargo {URI = /cargoes/}
Docker «REST with JSON»
{Image = ewolff/docker-java} * * «Execution Environment» «deploy»
Docker
{Image = ewolff/docker-java}

MSA stereotype definitions

MSA stereotype Specializes Semantics
«APIGateway» «UML::Node» The annotated node acts as an API gateway in a microservice architecture.
«Container» «UML::Node» The annotated node is a microservice container. Its execution environment denotes the virtualization technology.
«MicroserviceArtifact» «UML::Artifact» The annotated artifact is a physical representation of a deployable microservice.
«ServiceDiscovery» «UML::Node» The annotated node acts as a service discovery in a microservice architecture.

(c)

FIGURE 1. Applying domain-driven design (DDD) to microservice architecture (MSA). (a) The Cargo domain model (depicted as
a UML class diagram with DDD-specific stereotypes).1 (b) An intermediate model for the specification of microservice interfaces
deduced from the domain model (modeled with the SoaML [Service Oriented Architecture Modeling Language] UML profile7 and
MSA-specific stereotypes). (c) An intermediate model, also deduced from the domain model, for the specification of microservice
deployment (a UML deployment diagram with MSA-specific stereotypes).

38 I E E E S O F T WA R E | W W W. C O M P U T E R . O R G / S O F T W A R E | @ I E E E S O F T WA R E

Authorized licensed use limited to: UNIVERSIDADE FEDERAL DO ESPIRITO SANTO. Downloaded on July 03,2022 at 14:24:48 UTC from IEEE Xplore. Restrictions apply.
 Table 1. Domain-driven-design patterns for domain-driven microservice
design, in UML notation.5
Pattern name Example Description

Entity «Entity» Instances of domain concepts modeled as Entities are distinguishable from others by a
Customer
domain-specific identity.
tax ID

Value Object «ValueObject» Instances of domain concepts modeled as Value Objects are typically immutable and
Person
forename
lack a domain-specific identity. They might act as value containers when exchanging
lastname information between Bounded Contexts (see below).

Aggregate «AggregateRoot, Entity» An Aggregate is a cluster of associated Entity and Value Object instances. It is treated as
Car
a whole that can be accessed only by referencing its root Entity instance. Next to Bounded
Contexts, Aggregates might also denote a primary driver for domain decomposition.6
4

«ValueObject»
{aggregateRoot = Car}
Tire

Repository «Repository» A Repository permits access to persistent domain concept instances via operations that
Cars
perform instance selection based on given search criteria.
readByMarque(marque)

«Entity»
Car
marque

Service «Service» Services provide capabilities that are not the responsibility of Entities or Value Objects—
FundsTransferDomainService
e.g., control of business processes or domain concept instance transformations. A
transfer(accountFrom, accountTo,
amount)
special type of domain-driven-design service is domain services. They interact with
domain concept instances to realize business capabilities. For example, a funds transfer
* domain service might be responsible for coordinating credits and debits between banking
accounts.1 Services are parts of Bounded Contexts and are not to be confused with
«Entity» microservices that are derived from Bounded Contexts.
Account
accountNo
credit(amount)
debit(amount)

Specification «Entity» Specifications may be employed to determine if a domain concept instance fulfills a
Building
certain specification. Specification classes contain a set of Boolean operations to perform
specification checks.

«Spec»
BuildingInspection
isTechnicallyApproved(Building)
: Boolean

Bounded Context Bounded Contexts define scopes for enclosed domain concepts—i.e., boundaries for
concept validity and applicability. A functional microservice3 should be aligned to a
«BoundedContext» Bounded Context because, like a microservice, a context bundles and isolates coherent
Customer domain concepts and thus
• defines the scope of an isolated business capability,
• needs to explicitly define access to domain concept instances via exchange relationships
to other contexts, and
• has exactly one responsible team assigned.2

M AY/J U N E 2 0 1 8 | I E E E S O F T WA R E 39
Authorized licensed use limited to: UNIVERSIDADE FEDERAL DO ESPIRITO SANTO. Downloaded on July 03,2022 at 14:24:48 UTC from IEEE Xplore. Restrictions apply.
 FOCUS: MICROSERVICES

Contexts. So, challenges arise re- stereotype for generic service compo- environments specify the employed
garding domain model access and nents. For each context in a domain container technologies and images—
change management. model, the interface model contains e.g., Docker in Figure 1c.
First, it has to be decided which an eponymous microservice. Containers have a communica-
domain model parts are visible to SoaML expresses provided ser- tion path when an association exists
teams. One approach is to make vice interfaces as ports with outgo- between concepts of the deployed
the domain model completely ac- ing UML lollipops—i.e., solid lines microservices’ Bounded Contexts.
cessible. Alternatively, teams might starting from the port and ended Communication paths specify pro-
have insight into only their Bounded by a circle. Each lollipop exhibits tocols and message formats for
Contexts and associated concepts. the «Service» stereotype and interface container communication and cor-
Depending on the approach, organi- name. A microservice provides an in- respond to service interactions in the
zational efforts and possible model terface when at least one of the un- interface model, which also differen-
changes differ. derlying Bounded Context’s domain tiates service provider and requester
Teams might be permitted to concepts is associated and navigable roles. In Figure 1c, a communica-
change other teams’ Bounded Con- from another context. For example, tion path is modeled between the
texts. They would have to take into the Customer microservice in Figure 1b Cargo and Customer containers because
account that resolving and merging provides a CustomerAccess interface be- the Cargo and Customer Entities are as-
changes will be more difficult and cause the Customer Entity in Figure 1a sociated in Figure 1a. So, deployed
that new service dependencies will is associated with and navigable from microservices communicate via REST
be more likely. the Cargo Entity in the Cargo context. (Representational State Transfer) and
Required service interfaces are JSON (JavaScript Object Notation).
Means of Model-Driven modeled as requesting ports with Message-based communication could
Development to Cope the «Request» stereotype and interface be modeled by specifying a protocol
with Challenges name in SoaML. A microservice re- like AMQP (Advanced Message Queu-
In the following, we present three quires an interface when its context’s ing Protocol) on a communication path.
distinct means of MDD, each of concepts reference concepts of other Additionally, the deployment model
which addresses one of the chal- contexts in a navigable way. For contains infrastructure components—
lenges of domain-driven micro­ example, the Cargo microservice in i.e., service discovery and an API
service design described in the Figure 1b has a requesting port Cus- gateway.
section “Challenges of Domain- tomerAccess to consume the eponymous The intermediate models introduce
Driven Micro­s ervice Design.” interface of the Customer microservice. technical characteristics that inten-
It enables the Cargo service to associ- tionally are not in the domain model
Intermediate Models ate Cargo Entity instances with Custom- but substantiate MSA implementa-
Intermediate models show technical ers as modeled in Figure 1a. tion. The interface model shows de-
microservice characteristics from rel- Figure 1c shows an intermedi- duced microservices, interfaces and
evant viewpoints. A domain model ate UML deployment diagram de- operations with types, and service
should be transferred into interme- duced from the Cargo domain model dependencies. The deployment model
diate models specifying microservice (see Figure 1a). «MicroserviceArtifact» comprises technical information re-
interfaces and deployment. specializes UML’s «Artifact» ste- garding service endpoints, protocols,
Figure 1b shows an interface reotype. «MicroserviceArtifact» allows and message formats; deployment
model of the cargo system deduced explicit modeling of deployable technologies; and infrastructure com-
from the domain model in Figure micro­ service artifacts. The URI at- ponents. The model enables deduc-
1a. Simple Interfaces of the Service tribute specifies a deployed service’s tion of container configurations and
Oriented Architecture Modeling location. Each Bounded Context of deployment descriptors.
Language (SoaML) are used to con- a domain model is transferred to a
cisely model provided and required «MicroserviceArtifact» in the deployment Reducing Domain Model Informality
service interfaces.7 The «Microservice» model. Each artifact is deployed to a Domain model informality can sig-
stereotype identifies microservices. container identified by the «Container» nificantly be reduced with modeling
It specializes SoaML’s «Participant» stereotype. Container execution conventions.

40 I E E E S O F T WA R E | W W W. C O M P U T E R . O R G / S O F T W A R E | @ I E E E S O F T WA R E

Authorized licensed use limited to: UNIVERSIDADE FEDERAL DO ESPIRITO SANTO. Downloaded on July 03,2022 at 14:24:48 UTC from IEEE Xplore. Restrictions apply.
 One convention might be the pro- Customer and Location Entities in Figure Independent of the applied model
hibition of binary associations1— 1a. However, in certain situations access approach, explicit model
e.g., in Figure 1a, between Delivery it is sensible to model shared mod- management is necessary; i.e., a cen-
Specification and Location. This conven- els with reduced structures—e.g., to tral instance needs to keep track of
tion encourages modelers to clarify lower network traffic by transmit- changes from distributed teams and
which microservice is responsible for ting fewer attributes. Shared models incorporate them into a unified do-
requesting concept instances from can be modeled as classes referenced main model.
another microservice leveraging nav- from requesting contexts and depen- A policy regarding permissible
igability specifications (see the sec- dent on concepts in providing con- changes of Bounded Contexts or do-
tion “Deducing Microservices from texts. 5 They might be directly added main concepts of other teams should
Domain Models”). If this convention to interface models as operation re- be employed. Allowing such changes
is too strict, modelers should con- sult types. is sensible in situations where a do-
sider labeling the providing side of a main model is incomplete, to enable
binary association. For example, the Policies for Autonomous its collaborative completion. Consid-
modeling decision in Figure 1b that Domain Modeling ering Figure 1a, a sensible addition
the Cargo requests the Location micro­ Modeling policies for regulating do- of the Cargo team could be latitude and
service is based on the named end of main model access and permissible longitude fields in the Location Entity to
the Delivery Specification and Location asso- changes might be employed for dis- extend a Carrier Movement with geoloca-
ciation in Figure 1a. tributed, autonomous service teams. tion information.
In addition, modelers should Giving all teams complete insight However, allowing teams to
agree on the DDD patterns that lead into the domain model—i.e., by pro- change other teams’ contexts needs
to microservice interfaces in advance viding access to the file that physi- careful consideration. First, changes
of the modeling process. A conven- cally holds the model via shared might need to be resolved by involv-
tion might be that Repositories and storage—increases the set of domain ing those teams that changed the
Services result in interfaces when concepts that may be affected by model, are responsible for the af-
their maintained Entities are refer- changes. A more restrictive policy is fected context and microservice,
enced from external contexts. For to make only coherent parts of the and realize dependent services. Sec-
referenced concepts not maintained model accessible. First, each team ond, changes may introduce new
by Repositories or Services, another needs to have insight into its ser- service dependencies—e.g., by as-
convention should be established— vices’ Bounded Contexts. Second, it sociating concepts from different
e.g., deducing default interface op- needs access to associated concepts contexts.
erations. Furthermore, the return from other contexts. For example, For example, in Figure 1a the Cargo
types of methods should be explic- the team that implements the Cargo team might associate the Customer and
itly modeled if they cannot be de- microservice of Figure 1a needs to Location Entities from the eponymous
duced from the domain model. For know the structures of the Customer contexts to add address information
example, if a method is not part of a and Location Entities. In contrast, the to Customers. The Customer microservice
Repository or Service in which its re- Customer team needs access to only its then would newly require informa-
turn type is typically the maintained Bounded Context as it does not ref- tion from the Location microservice.
Entity type, unambiguous return erence other contexts’ concepts in a Hence, the Customer and Location teams
type deduction might be impossible. navigable way (see the section “In- would be affected by a change intro-
An additional convention could de- termediate Models”). duced by the Cargo team.
termine that domain model methods Partial model access fosters low
with public UML visibility result in service coupling as each team has Tools for Practical
interface operations. insight into only its contexts and a Domain-Driven
Model informality might ad- minimum of context-external con- Microservice Design
ditionally be reduced by defining cepts. However, it requires addi- Tool support is crucial for practical
shared models. 2 As a convention, tional effort to split the model file MDD.4 Currently, few MDD tools
the structures of shared models in into several files containing only exist for domain-driven microservice
Figure 1b correspond directly to the team-relevant contexts and concepts. design.

M AY/J U N E 2 0 1 8 | I E E E S O F T WA R E 41
Authorized licensed use limited to: UNIVERSIDADE FEDERAL DO ESPIRITO SANTO. Downloaded on July 03,2022 at 14:24:48 UTC from IEEE Xplore. Restrictions apply.
 FOCUS: MICROSERVICES

Domain Modeling.” The DDD pro-

ABOUT THE AUTHORS

file, together with concrete usage

FLORIAN RADEMACHER is a PhD student and research instructions and examples, can be
associate at the Institute for the Digital Transformation of found at github.com/SeelabFhdo
Application and Living Domains (IDiAL) at the Dortmund /ddmm-uml-profile.
University of Applied Sciences and Arts. His research interests AjiL is an Eclipse-based tool for
include model-driven development, specifically the design and graphical MSA modeling. It features
implementation of domain-specific modeling languages, and a diagram editor for modeling rudi-
service-based architectures, with a focus on microservice mentary domain models, functional
architecture. Rademacher received an MS in applied computer and infrastructure microservices,
science from the Dortmund University of Applied Sciences and and provided and required inter-
Arts. Contact him at [email protected]. faces. Thus, AjiL facilitates creat-
ing intermediate models for service
interfaces (see the section “Inter-
JONAS SORGALLA is a research associate at the Institute for mediate Models”). AjiL ships with
the Digital Transformation of Application and Living Domains a code generator that produces
(IDiAL) at the Dortmund University of Applied Sciences and Arts. micro­ service implementations from
His primary research interest is model-driven development, with AjiL models. The generated Java
a focus on participatory design of domain-specific modeling code is based on Spring Boot and
languages. Sorgalla received an MS in applied computer science Spring Cloud. It is directly runna-
from the Dortmund University of Applied Sciences and Arts. ble and comprises interface imple-
Contact him at [email protected]. mentations, stubs for implementing
services’ business logic, and con-
SABINE SACHWEH is professor of software engineering at figuration files for infrastructure
the Dortmund University of Applied Sciences and Arts. She’s components. However, AjiL cur-
also a spokesperson for the university’s Institute for the Digital rently does not support round-trip
Transformation of Application and Living Domains (IDiAL) and engineering.4 The tool is available at
the head of the institute’s Smart Environments Engineering github.com/SeelabFhdo/AjiL.
Laboratory. Her research interests include social platforms The profile and AjiL are actively
and computer-supported communication for groups of socially used in industry-related research
underprivileged persons, advanced interaction techniques, projects. Current development ef-
and the challenges of digital transformation in industrial forts focus on integrating both
contexts. Sachweh received her PhD in computer science tools with the aim to automate the
from Paderborn University. Contact her at sabine.sachweh@ deduction of intermediate models
fh-dortmund.de. from domain models. Therefore,
profile-based domain models are
to be automatically transformed
into AjiL models for subsequent
technology-related refinements and
For creating DDD-based domain informality (see the section “Reduc- code generation.
models like Figure 1a, a UML profile ing Domain Model Informality”).

D
exists. It comprises stereotypes for The profile is developed with the
DDD patterns (see Table 1). Mod- Eclipse Papyrus modeling environ- omain-driven design pro-
elers can turn UML class diagrams ment and can be applied to existing vides, among other things,
into domain models by applying the Papyrus-based UML class diagrams. the modeling means for
stereotypes to existing elements. The The resulting domain model file software design to decompose do-
profile’s constraints for stereotype may be distributed across micro­ mains into bounded contexts.
application following DDD seman- service teams as described in the Thereby, each context clusters coher-
tics5 aid in reducing domain model section “Policies for Autonomous ent domain concepts and denotes a

42 I E E E S O F T WA R E | W W W. C O M P U T E R . O R G / S O F T W A R E | @ I E E E S O F T WA R E

Authorized licensed use limited to: UNIVERSIDADE FEDERAL DO ESPIRITO SANTO. Downloaded on July 03,2022 at 14:24:48 UTC from IEEE Xplore. Restrictions apply.
 candidate for a microservice. How- 3. M. Richards, Microservices vs. 7. Service Oriented Architecture
ever, domain models are typically Service-Oriented Architecture, Modeling Language (SoaML)
underspecified, which poses several O’Reilly Media, 2015. Specification Version 1.0.1, Object
challenges when applying DDD to 4. B. Selic, “The Pragmatics of Model- Management Group, 2012; www
MSA. In this article we discussed Driven Development,” IEEE Soft- .omg.org/spec/SoaML.
challenges in deducing microservices ware, vol. 20, no. 5, 2003, pp. 19–25.
and related infrastructure compo- 5. F. Rademacher, S. Sachweh, and A.
nents from domain models, as well Zündorf, “Towards a UML Profile
as domain modeling in microservice for Domain-Driven Design of Micro­
teams. We then presented selected service Architectures,” Software
means and tools of MDD to cope Engineering and Formal Methods,
with such challenges. 2018, Springer, pp. 230–245.
6. C. Richardson, “Developing
References Transactional Microservices Using
1. E. Evans, Domain-Driven Design, Aggregates, Event Sourcing and
Addison-Wesley, 2004. CQRS—Part 1,” InfoQ, 3 Oct. 2016; Read your subscriptions
2. S. Newman, Building Microservices: www.infoq.com/articles/microservices through the myCS
publications portal at
Designing Fine-Grained Systems, -aggregates-events-cqrs-part-1-
O’Reilly Media, 2015. richardson.
http://mycs.computer.org

Take the
CS Library
wherever
you go!
IEEE Computer Society magazines and Transactions are now
available to subscribers in the portable ePub format.

Just download the articles from the IEEE Computer Society Digital
Library, and you can read them on any device that supports ePub.
For more information, including a list of compatible devices, visit

www.computer.org/epub

M AY/J U N E 2 0 1 8 | I E E E S O F T WA R E 43
Authorized licensed use limited to: UNIVERSIDADE FEDERAL DO ESPIRITO SANTO. Downloaded on July 03,2022 at 14:24:48 UTC from IEEE Xplore. Restrictions apply.