Journal of Distributed Software Engineering, Architecture and Design
Mapping Business Capabilities to Services
<div class="cs-rating pd-rating" id="pd_rating_holder_1819065_post_2124"></div>
<p class="wp-block-paragraph">One of the key questions around API strategy we get asked is <em>how do we map business capabilities to services</em>. An approach is to use domain driven design and build domain services, in this post we will look at what this looks like</p>
<p class="wp-block-paragraph"><strong>Capabilities</strong> </p>
<p class="wp-block-paragraph">Businesses domains offer capabilities. Given domains are classified into core, supporting or generic it helps to think of the domain services as core, supporting or generic </p>
<p class="wp-block-paragraph"></p>
<figure class="wp-block-image size-large"><a href="https://alok-mishra.com/wp-content/uploads/2021/07/screen-shot-2021-07-15-at-11.07.52-am-1.png"><img src="https://alok-mishra.com/wp-content/uploads/2021/07/screen-shot-2021-07-15-at-11.07.52-am-1.png?w=1024" alt="" class="wp-image-2149" /></a><figcaption>Business Domains an example</figcaption></figure>
<div class="wp-block-image"><figure class="aligncenter size-large is-resized"><a href="https://alok-mishra.com/wp-content/uploads/2021/07/screen-shot-2021-07-15-at-9.15.32-am.png"><img src="https://alok-mishra.com/wp-content/uploads/2021/07/screen-shot-2021-07-15-at-9.15.32-am.png?w=640" alt="" class="wp-image-2128" width="388" height="303" /></a><figcaption>Source: https://github.com/ddd-crew/ddd-starter-modelling-process</figcaption></figure></div>
<p class="wp-block-paragraph">Domain capabilities expressed as software features can then be written down as<em> desired capability in domain service</em></p>
<figure class="wp-block-image size-large"><a href="https://alok-mishra.com/wp-content/uploads/2021/07/screen-shot-2021-07-15-at-11.07.57-am-1.png"><img src="https://alok-mishra.com/wp-content/uploads/2021/07/screen-shot-2021-07-15-at-11.07.57-am-1.png?w=1024" alt="" class="wp-image-2150" /></a><figcaption>Business Capabilities in Domains</figcaption></figure>
<p class="wp-block-paragraph">For example, the following ask comes from our customer domain where customer management, case management, document management happen in the context of a customer</p>
<div class="wp-block-image"><figure class="aligncenter size-large"><a href="https://alok-mishra.com/wp-content/uploads/2021/07/screen-shot-2021-07-15-at-8.53.09-am.png"><img src="https://alok-mishra.com/wp-content/uploads/2021/07/screen-shot-2021-07-15-at-8.53.09-am.png?w=664" alt="" class="wp-image-2130" /></a><figcaption>A sample of desired capability in a domain service software </figcaption></figure></div>
<p class="wp-block-paragraph">And to realise this we need a domain service, lets call this Customer API. It is interesting to note here how that the language of <em><strong>we need an API strategy </strong></em>translates to <em><strong>we need a set of domain services </strong></em></p>
<figure class="wp-block-image size-large"><a href="https://alok-mishra.com/wp-content/uploads/2021/07/screen-shot-2021-07-15-at-9.25.39-am.png"><img src="https://alok-mishra.com/wp-content/uploads/2021/07/screen-shot-2021-07-15-at-9.25.39-am.png?w=1024" alt="" class="wp-image-2132" /></a><figcaption>Domain Service to implement the capability</figcaption></figure>
<p class="wp-block-paragraph"><strong>Applying domain driven design</strong></p>
<p class="wp-block-paragraph">It helps at this point to recognise that a domain service can be described using domain driven design (DDD) as an Open Host Service (OHS) with perhaps a Published Language (OHS+PL) and relies on Domain Aggregates (Customer Contact, Customer Case etc) which emerge from bounded contexts (Customer Contact Management, Case Management etc) </p>
<p class="wp-block-paragraph">Applying this to other concepts we can see how context mapping and event-storming notation fit here </p>
<figure class="wp-block-image size-large"><a href="https://alok-mishra.com/wp-content/uploads/2021/07/screen-shot-2021-07-15-at-9.28.24-am.png"><img src="https://alok-mishra.com/wp-content/uploads/2021/07/screen-shot-2021-07-15-at-9.28.24-am.png?w=1024" alt="" class="wp-image-2134" /></a><figcaption>Bounded Contexts, Aggregates, Commands, Queries and Events</figcaption></figure>
<p class="wp-block-paragraph">The bounded contexts that form the business context boundaries within a domain contain the language to define the model (aggregate). The model is expressed in our software (domain service) allowing mutation (state changes) via commands, query and publishing business events when there is a state change (domain aggregate events)</p>
<p class="wp-block-paragraph"><strong>Putting it all together into a domain service</strong></p>
<p class="wp-block-paragraph">So what is a domain service? It is a namespace with a specific context under which business context services are provided. For example, in a customer domain service all the operations provided by the domain service are in the context of a customer</p>
<p class="wp-block-paragraph">So putting all these concepts together we get a domain service with a base uri (top-level context root) and services under that context. Note that I am not implying the contextual services are deployed together, they just belong to a common namespace</p>
<figure class="wp-block-image size-large"><a href="https://alok-mishra.com/wp-content/uploads/2021/07/screen-shot-2021-07-15-at-9.36.50-am.png"><img src="https://alok-mishra.com/wp-content/uploads/2021/07/screen-shot-2021-07-15-at-9.36.50-am.png?w=1024" alt="" class="wp-image-2137" /></a></figure>
<p class="wp-block-paragraph"><strong>Ownership and Communication: Team Topology </strong></p>
<p class="wp-block-paragraph">Given our software architecture will follow the organisation of the teams (Conway’s law) it is also key to organising them along the bounded contexts. An example is provided below and shows how capability is shared across teams in a domain </p>
<figure class="wp-block-image size-large"><a href="https://alok-mishra.com/wp-content/uploads/2021/07/screen-shot-2021-07-15-at-9.40.10-am.png"><img src="https://alok-mishra.com/wp-content/uploads/2021/07/screen-shot-2021-07-15-at-9.40.10-am.png?w=1024" alt="" class="wp-image-2139" /></a><figcaption>Contextual Software Teams</figcaption></figure>
<p class="wp-block-paragraph"><strong>Summary</strong></p>
<p class="wp-block-paragraph">Mapping business capabilities to domain services requires enumerating the capabilities, identifying what will be expressed in software and then applying domain driven design to work out the business contexts, aggregates and services </p>
<p class="wp-block-paragraph">This process also neatly aligns to an API strategy – the process where where we analyse current state, build a future state (using the techniques above) and plan a roadmap. More on API strategy and also API Market Place in future posts</p>
One of the key questions around API strategy we get asked is how do we map business capabilities to services. An approach is to use domain driven design and build domain services, in this post we will look at what this looks like
Capabilities
Businesses domains offer capabilities. Given domains are classified into core, supporting or generic it helps to think of the domain services as core, supporting or generic
Domain capabilities expressed as software features can then be written down as desired capability in domain service
Business Capabilities in Domains
For example, the following ask comes from our customer domain where customer management, case management, document management happen in the context of a customer
A sample of desired capability in a domain service software
And to realise this we need a domain service, lets call this Customer API. It is interesting to note here how that the language of we need an API strategy translates to we need a set of domain services
Domain Service to implement the capability
Applying domain driven design
It helps at this point to recognise that a domain service can be described using domain driven design (DDD) as an Open Host Service (OHS) with perhaps a Published Language (OHS+PL) and relies on Domain Aggregates (Customer Contact, Customer Case etc) which emerge from bounded contexts (Customer Contact Management, Case Management etc)
Applying this to other concepts we can see how context mapping and event-storming notation fit here
Bounded Contexts, Aggregates, Commands, Queries and Events
The bounded contexts that form the business context boundaries within a domain contain the language to define the model (aggregate). The model is expressed in our software (domain service) allowing mutation (state changes) via commands, query and publishing business events when there is a state change (domain aggregate events)
Putting it all together into a domain service
So what is a domain service? It is a namespace with a specific context under which business context services are provided. For example, in a customer domain service all the operations provided by the domain service are in the context of a customer
So putting all these concepts together we get a domain service with a base uri (top-level context root) and services under that context. Note that I am not implying the contextual services are deployed together, they just belong to a common namespace
Ownership and Communication: Team Topology
Given our software architecture will follow the organisation of the teams (Conway’s law) it is also key to organising them along the bounded contexts. An example is provided below and shows how capability is shared across teams in a domain
Contextual Software Teams
Summary
Mapping business capabilities to domain services requires enumerating the capabilities, identifying what will be expressed in software and then applying domain driven design to work out the business contexts, aggregates and services
This process also neatly aligns to an API strategy – the process where where we analyse current state, build a future state (using the techniques above) and plan a roadmap. More on API strategy and also API Market Place in future posts
Alok brings experience in engineering and architecting distributed software systems from over 20 years across industry and consulting. His posts focus on Systems Integration, API design, Microservices and Event driven systems, Modern Enterprise Architecture and other related topics
View all posts by alokmishra