REL03-BP02 Build services focused on specific business domains and functionality
Service-oriented architectures (SOA) define services with well-delineated functions defined by business needs. Microservices use domain models and bounded context to draw service boundaries along business context boundaries. Focusing on business domains and functionality helps teams define independent reliability requirements for their services. Bounded contexts isolate and encapsulate business logic, allowing teams to better reason about how to handle failures.
Desired outcome: Engineers and business stakeholders jointly define bounded contexts and use them to design systems as services that fulfill specific business functions. These teams use established practices like event storming to define requirements. New applications are designed as services well-defined boundaries and loosely coupling. Existing monoliths are decomposed into bounded contexts
Domain-oriented services are executed as one or more processes that don’t share state. They independently respond to fluctuations in demand and handle fault scenarios in light of domain specific requirements.
Common anti-patterns:
-
Teams are formed around specific technical domains like UI and UX, middleware, or database instead of specific business domains.
-
Applications span domain responsibilities. Services that span bounded contexts can be more difficult to maintain, require larger testing efforts, and require multiple domain teams to participate in software updates.
-
Domain dependencies, like domain entity libraries, are shared across services such that changes for one service domain require changes to other service domains
-
Service contracts and business logic don’t express entities in a common and consistent domain language, resulting in translation layers that complicate systems and increase debugging efforts.
Benefits of establishing this best practice: Applications are designed as independent services bounded by business domains and use a common business language. Services are independently testable and deployable. Services meet domain specific resiliency requirements for the domain implemented.
Level of risk exposed if this best practice is not established: High
Implementation guidance
Domain-driven design (DDD) is the foundational approach of designing and building software around business domains. It’s helpful to work with an existing framework when building services focused on business domains. When working with existing monolithic applications, you can take advantage of decomposition patterns that provide established techniques to modernize applications into services.
Domain-driven design
Implementation steps
-
Teams can hold event storming
workshops to quickly identify events, commands, aggregates and domains in a lightweight sticky note format. -
Once domain entities and functions have been formed in a domain context, you can divide your domain into services using bounded context
, where entities that share similar features and attributes are grouped together. With the model divided into contexts, a template for how to boundary microservices emerges. -
For example, the Amazon.com website entities might include package, delivery, schedule, price, discount, and currency.
-
Package, delivery, and schedule are grouped into the shipping context, while price, discount, and currency are grouped into the pricing context.
-
-
Decomposing monoliths into microservices outlines patterns for refactoring microservices. Using patterns for decomposition by business capability, subdomain, or transaction aligns well with domain-driven approaches.
-
Tactical techniques such as the bubble context
allow you to introduce DDD in existing or legacy applications without up-front rewrites and full commitments to DDD. In a bubble context approach, a small bounded context is established using a service mapping and coordination, or anti-corruption layer , which protects the newly defined domain model from external influences.
After teams have performed domain analysis and defined entities and service contracts, they can take advantage of AWS services to implement their domain-driven design as cloud-based services.
-
Start your development by defining tests that exercise business rules of your domain. Test-driven development (TDD) and behavior-driven development (BDD) help teams keep services focused on solving business problems.
-
Select the AWS services
that best meet your business domain requirements and microservice architecture: -
AWS Serverless
allows your team focus on specific domain logic instead of managing servers and infrastructure. -
Containers at AWS
simplify the management of your infrastructure, so you can focus on your domain requirements. -
Purpose built databases
help you match your domain requirements to the best fit database type.
-
-
Building hexagonal architectures on AWS outlines a framework to build business logic into services working backwards from a business domain to fulfill functional requirements and then attach integration adapters. Patterns that separate interface details from business logic with AWS services help teams focus on domain functionality and improve software quality.
Resources
Related best practices:
Related documents:
Related examples:
Related tools:
