Service Cut by DDD

Context

Microservices are in use or are planned to be adopted. The service cut is being planned or reconsidered.

Problem

• A bad service cut might lead to losing the benefits of doing microservices or to high refactoring costs later on.

Solution

Use Domain-Driven Design techniques to build a domain model. Use bounded contexts or subdomains as a natural boundary for microservices.

Domain-Driven Design (DDD) is the state-of-the-art approach to determine a suiting cut into microservices. In the resulting domain model, each bounded context or subdomain is mapped to one microservice.

Among others, the following workshop formats can be used to determine bounded contexts or subdomains:

• Event-Storming
• Grouping domain vocabulary
• Stacking User Stories
• Whiteboarding

"Grouped around business capabilities" is an often-cited phrase for microservice characteristics. The term "business capability" is grounded in economics relating to the abilities of a company to achieve its goals - a rather abstract concept. Bounded contexts group functionality into a business capability which can then be implemented as a microservice L21. This effect emerges if the application domain is the companies' business, and the goal of the software system is to support the company in its business.

Maturity

Proposed, requires evaluation.

Sources of Evidence

Code "Domain-Driven Design"

L3:

• DDD and bounded context pattern are common practices / state-of-the-art to migrate towards microservices

L4:

• Context: interview
• Microservices use better practices from other domains
• Strategic design of DDD: bounded context, subdomains, how separate domains, how partition problem domain into smaller ones to manage them
• Need to understand what the business problems are, the business landscape looks like, the business processes are
  • then drive a software product underneath that
  • that's DDD at its heart
• Colleague: "business and architecture isomorphism"
  • business and design of architecture should be very similar
  • look at business, should see IT systems
  • look at architecture, should see business

L7:

• Tenets of microservices
  • "Business-driven development practices and pattern languages such as domain-driven design (DDD) are employed to identify and conceptualize services."
  • both Lewis&Fower and Newman's principles include to model around business concepts
    • intent: domain model and ubiquitous language make code understandable and easy to maintain
  • SOA also propagates this since 2003
    • more focused on object-oriented analysis and design

L8:

• DDD played key role in emergence of microservice architectural style
  • guided by principles as bounded context

L12:

• Citation that Domain Driven Design and Bounded Contexts are common practices to transform system to microservices
  • state of the art!

L14:

• Vertical decomposition for microservices
  • propose decomposition into self-contained systems (SCS) along business services
  • Amazon follow this approach, otto.de as well
• Case at otto.de
  • vertically decomposed system
  • Started with cut into Product, Order, Promotion, Search/Navigation verticals
    • now 45 applications and 12 verticals
  • "Vertical" responsible for a single bounded context in a business domain
    • can be as small as a microservice, but can be more coarse grained (most of the times)
      • => further refine by either into new vertical or cutting into distributed system of microservices

L16:

• cites Newman to do domain driven design
  • business domain knowledge at core of development process
  • Domain experts included more closely into loop of software engineering

L19:

• in enterprise context, microservices be designed with business-oriented driver in mind
  • services should mimic
    • not organization
    • not technological or communication boundaries
    • but be modelled around specific business domain
• Bounded context encapsulates details of single domain
  • data models, domain model, ...
  • defines integration points with other bounded contexts
  • critical to have for microservices
  • the more boundaries between domains well-defined, the more able to reason about service design end efficient size
  • sometimes shared models, sometimes models only need to exist inside f each bounded context

L20:

• Context: survey for gains and pains
• Pain/Challenge: dimensioning of services
  • as primary pain at design time
  • difficult to identify business capabilities / bounded contexts
  • should be assigned to each microservice
  • reason: boundaries among different capabilities/contexts are usually not that sharp
• Gain: bounded contexts
  • intrinsically peculiar with microservices
  • as primary architectural gain
    • => brings benefits
  • makes microservice self-contained
    • => analyzed, understood, updated without knowing rest of architecture

L21:

• cites basic principle of microservices: bounded context
  • related functionalities combined into single business capability
  • each microservice implements such capability
  • perfect alignment between business capabilities and system structure
    • make it easy to locate functionality => update/fix it
• relies on Domain-Driven Design
  • aims for high cohesion
    • high load delimited to set of associated microservices
    • specific service under load can be scaled (relocation to bigger host / replication)

L22:

• James Lewis
  • Microservices have number of complementary practices
    • DDD
      • foundational piece of thinking in terms of microservices
      • break into smaller bounded contexts
      • build teams around them
      • concrete interfaces at their interfaces
      • shared nothing approach to domain logic
      • (+) decouples teams and software => innovation speed
    • More tactical DDD patterns (aggregate, entity, ...) less important
      • since smaller services => continuous refactoring
      • "products not projects"
    • Techniques to understand domains
      • event storming workshops
      • white-boarding
      • stacking user stories in piles
        • group then in any number of lightweight ways
      • significant organizational top-down restructuring => bounded contexts emerged automatically
        • service architecture then follows business architecture
          • business-level value streams and communication paths => service interaction
  • Static analysis => understand namespaces of a product
    • refactor namespaces into discrete bounded contexts
    • duplicate code where necessary
    • depends on amount of dept and age of code base: if very cohesive code, not applicable
• Nicolai: microservice principles were used before as well
  • business-driven service design
• Mike
  • scalable architecture is usually good ad sharing domain understanding
    • either architecture designed around single set of domains
    • or architecture is designed around the "shared domain understanding" concept itself => more abstract, more challenging
  • DDD falls short on systems that focus on the interface between components
  • Hypermedia concepts in comm tech allow to safely deal with changes in Bounded Context over time
    • objects change shape and components modify their bounded context
    • but services still use the same standard message models but with new hypermedia controls (new links and forms)
• Summary
  • Choose decomposition approach based on context, vision, requirements, and coupling criteria.

L27:

• Semantic coupling strategy
  • derived from concept of bounded contexts
  • by examining contents and semantics of source code files (automated algorithm)

L31:

• Context: migration patterns
• Pattern MP3 "Decompose the monolith"
  • Context:
    • Migrating from monolithic system
    • complex domain
    • one of the following applies
      • complexity leads to low comprehensibility of source code
      • different non-functional requirements for different parts of the system
      • every change requires whole redeployment although that is not desired
  • Problem:
    • How decompose to smaller chunks? How big should those chunks be?
  • Solution:
    • DDD to identify subdomains => bounded contexts
      • 1:1 mapping if greenfield
      • not always possible in legacy systems => suboptimal solution although big changes
    • BC = deployable unit
    • Can be an iterative process, but target architecture should be somewhat clear
    • DDD for initial decomposition;
    • Further decomposition can be done by
      • result of different nonfunctional requirements for different parts of a BC.
      • DDD again
    • Size of BC hard to recommend, depends on requirements
      • Initially: large as whole domain; then split and incrementally get to lower size
  • Challenges:
    • Bad decomposition can lead to performance issues
      • e.g. chatty services
  • Alternative patterns
    • MP4: Decompose based on data ownership
    • MP5: Change code dependency to service call
• In 3 case studies found most often compared to alternatives
  • heads-on with MP5: change code dependency to service call
  • significant difference in occurrences only in one case though

L34:

• Alternative to a canonical data model: Bounded contexts by DDD
  • each service operates with particular business objects in a specific context
    • consider some attributes, ignore others
  • large model divided into small contexts
    • allows modeling business objects differently based on particular needs
    • independence to design their needs required because not all services have same needs

L42:

• Context: survey
  • significance to have crystal clear understanding of domain to identify bounded contexts properly
    • => define sharp boundaries
  • most relevant activities
    • domain composition (11/18)
    • service identification (11/18)
    • DDD practices (10/18)
    • system decomposition (9/18)

L62:

• References Richardsons's approaches for deecomposiotion:
  • by business capability, by ddd sub-domain, by verb or use case, by nouns or resources

LN39:

• Reference to Lewis and Flowler's notion of a bounded context (originals from DDD)

LN44:

• Do one thing and do it well: bounded cnotexts and DDD usually result in smaller codebases per microservices

LM43:

• Context: SLR findings about microservices in DevOps
• Table 10: lists the DDD pattern
• S28 recommends DDD for service decomposition
  • architects identify bounded context (capabilities within system)
  • can be used as starting point for defining microservices
• S12 and S33 also report decomponsition patterns, example: DDD

LM45:

• Context: interviews and insights from multiple cases on technologies and sw quality in MSA
• C8-S12
  • 45 services organized in 5 domains with several subdomains or "verticals"
  • used DDD for decomponsition, and event storming
• C6-10
  • functional or feature-oriented decomposition
  • DDD not used due its perceived complexity
• DD is often cited in literature, but only 3 participants reported its explicit use

LM47:

• Context: SLR with tactics to achieve quality attributes
• Decomposition tactics o reduce semantic coupling
  • among other: according bounded context from DDD

Interview B:

• They do DDD to design domain model
  • Microservice is well described as a bounded context
    • self-contained block/service with clear API, distinct contract
    • independently developed, built, tested, deployed, scaled, replaced based on contract
    • not size important, but the self-containment and independence

Interview C:

• Event-storming technique and similiar techniques
  • need to get into the focus of requirements engineers
  • need to learn about those techniques, world is moving fast, often not time for education

Interview D:

• DDD is a good solution
• Some call it DDD but don't implement loose coupling on domain level
  • => knowing patterns doesn't mean to know how to use them
    • often use data entities under the pretext of DDD
    • with all its problems (see other code!)

Interview E:

• DDD also relevant for cutting frontend into micro-Frontends
  • DDD comes before deciding for micro-frontends
• Components between domains
  • hard to resolve; depedent on domain but also on mindest of engineers
  • Separate ways as strategy if you have multiple domains with different views on entity
    • often easier than you might think
    • need to get away from DRY principle
    • is not necessaryily a redundancy => different views
  • still, sometimes global components make sense
    • if same view on it from every angle

Code "Collection: Go by business process, not domains"

L22:

• when migrating
  • clearify domains, then clean up
  • when you start with the change, go business process by business process, not domain by domain.

L62:

• References Richardsons's approaches for deecomposiotion:
  • by business capability, by ddd sub-domain, by verb or use case, by nouns or resources

Code "Collection: Stacking User Stories"

L22:

• Example techniques to do DDD
  • User Story Stacking
    • (+) group user stories in any number of lightweight ways

Code "Collection: Whiteboarding"

L22:

• Example techniques to do DDD
  • Whiteboarding

Code "Collection: Event-Storming Workshops"

L22:

• Example techniques to do DDD
  • Event storming workshops

LM45:

• Context: interviews and insights from multiple cases on technologies and sw quality in MSA
• C8-S12
  • 45 services organized in 5 domains with several subdomains or "verticals"
  • used DDD for decomponsition, and event storming

Interview C:

• Event-storming technique and similiar techniques
  • need to get into the focus of requirements engineers
  • need to learn about those techniques, world is moving fast, often not time for education

Code "Collection: Group domain vocabulary"

L27:

• Context: automatically support with service cut
• Semantic coupling strategy
  • DDD as promising design rationale for microservice boundaries
  • examine contents and semantics of source code file through information retrieval techniques
    • couple together classes containing code about the same "things"
    • => identify domain concepts based son source code expressions (variable names, method names, ...)
    • apply "term-frequency inverse-document-frequency method"
• Evaluation: comparatively good results in terms of team size and average domain redundancy

L60:

• Context: automatically support with service cut
• based on OpenAPI spec
• use vocabulary, semantic assessment

LN39:

• Cites Richardson that bounded contexts can be separated by verbs (use cases) or nouns (resources)
• Lists it as further approach

Code "Collection: Term Business Capabilities"

Disclaimer: DDD not directly mentioned, but in literature kind of used as synonym for using DDD / DDD one of the ways to end up with services organized around business capabilities

L7:

• Organized around business capabilities / model around business concepts
• SOA: concept also present

L20:

• boundaries between capabilities/contexts not that sharp
  • difficult to determine partitioning into bounded contexts, "as boundaries among different business capabilities" are not that sharp
  • => challenge to identify

L21:

• Bounded context groups functionality into a single business capability
  • alignment of business capabilities and system structure
    • easy to know where functionality is, update or fix it
• Microservice provide single business capability only
  • => maintainability, extendability

L22:

• services built around business capabilities (cites Lewis&Fowler)

L41:

• microservice expected to implement single business capability
  • delivered and updated independently
  • discovering bugs or adding minor improvements does not impact other services on their releases

L46:

• SOA and Microservices organized around business capabilities; business-significant boundaries

L62:

• References Richardsons's approaches for deecomposiotion:
  • by business capability, by ddd sub-domain, by verb or use case, by nouns or resources

LN39:

• Decomposition around business capabilities means functional decomposition perspective
  • dependencies on technical layers greatly reduced

LN41:

• "Built around business capabilities" in definition of microservices

LM43:

• Context: SLR findings about microservices in DevOps
• S41 suggests microservices around business capabilities can address scalability issue

LM48:

• Context: microservice migration describes an examples project (FX Core) and compares back to monolith
• bounded context - focus on business capabilities
  • related functionalitites combined into business capability => implemented as a service
  • needs to be business-driven and outside-in: led by necessity of stakeholders
  • business functionalities defined by comm. with forex traders
  • if business functionality isolated and sufficiently big or shared among other functions, should result in new service
  • sometimes first combine, then later split

Interview D:

• important to organize around business capabilities
  • often not done
• DevOps => ends in capability-oriented modularization between teams; otherwise no independence possible
  • Microservices as answer, not question