This document discusses key concepts related to domain-driven design and microservices including: 1. Boundaries define the functional, operational, and data limits of a microservice. Bounded contexts represent a logical subset of one or many business capabilities from the perspective of a role. 2. A business capability describes what a business does to reach its objectives, rather than how it does it. Business domains represent areas of business with their own semantics, regulations, rules, and governance. 3. A context map makes context boundaries explicit and models the possible inter-connections between business contexts. Microservices are small, independently deployable services built around business capabilities.

1. Simplified Domain Driven Development & MicroService Meta-Model
Boundary
The Merriam-Webster defines boundary as a limit of a subject. In the context of MicroServices, boundary refers to the
functional,operational and data limits associatedwith a piece of softwarethat exhibit the characteristicsof MicroServices.
(Business)Bounded Context
Represents a logical subset of one or many business capabilities that provides business value from the perspective of a role.
Therefore,the boundaries of the logical subset define a business context in which the role is bound to operate.
Business Capability
Describes what a business does to reach its objectives, instead of how it does it (business processes). The goal of business
capabilities is to model a business on its most stable elements, as they are the top layer of the business architecture. Business
capabilities are governed by the business principles of the organization. The capabilities are realized by business processes and
performed by one or many roles (i.e. an individual or team) in the organization.
Business Domain
An area of business (by engaging in commerce) with its own semantics, regulations,rules, functionalbehavior, and governance.
Context Map
A Context Map is designated as the primary tool used to make context boundaries explicit (source: Domain Driven Design © 2003
Eric Evans)
MicroService
A MicroService architectural style is an approach to developing a single application as a suite of small services (MicroServices),
each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services or
MicroServices are built around business capabilities and independently deployable by fully automated deployment machinery.
There is a bare minimum of centralized management of these services, which may be written in different programming
languages and use different data storagetechnologies(source: ThoughtWorks).
Model
A model serves as an abstraction or an approximate representation of a real item that is being built. A model may either be
physical or less tangible, such as financial models. In the context of MicroServices, models capture the (business) elements
within a ( business) bounded context, along with their inter-relationships.
Role
The responsibility for performing specific behavior, to which an actor can be assigned.
Actor
An organizationalentity that is capable of performing behavior.
© 2016 PhilippeAssouline
DDD & MicroService Meta Model
Business Architecture
Meta-Model

2. Methodology for MicroServices Inference: A Traceable Approach
One or many roles must first be
selected, as they define the number
and shape of business bonded contexts.
The role’s viewpoints are then applied
to an organization’s Business Capability
Model to identify business bonded
contexts.
Once business bounded contexts had
been identified, a Context Map is then
created to understand the possible
inter-connections and inter-
dependencies between business
contexts.
Subsequently, user stories are
established for each business bonded
context associated with each of the
roles.
Once user stories had been
written, various models are
developed to understand both,
business and technology elements,
that are necessary to digitize the
business bounded contexts under
consideration.
The proposed list of models is not
exhaustive. Additional artifacts
may be developed based on needs.
A gap analysis and
rationalization of all
business and
technology items is
suggested to resolve
possible conflicts
among elements
bearing the same
name but with
different behaviors.
Similar to the CRC agile
technique, the Service
Responsibly Cards capture the
MicroServices’ single functional
responsibility (SRP Principle).
Coupled with a MicroServices
Map, collaborations,
interactions, and sequencing
between MicroServices can be
modeled to validate the
proposed technology solutions,
and understand the messages
being exchanged among them.© 2016 PhilippeAssouline
MicroServices are
subsequently inferred after
both business and
technology elements had
been rationalized.
The discovery of
MicroServices is likely to be
an iterative process,
concluding with the
promotion of MicroServices
from candidate to first-class
citizen.