Practical Architecture - DDD

When will we consider to create an aggregate microservice?

• When our business unit is in a monolith (backend/iot service)

• When we are part of a new squad in a new product domain

• When we have a new “concept” that is part of an MVP

• When we have a well defined business unit which has an identity and state management.

When will we consider to create a bounded context microservice?

• When we have a new domain with too many unknowns

• When we have a new squad

• When we have aggregates which are related to each other

• When we have an extra field to add to an aggregate

When will we consider an aggregate as complex aggregate microservice?

• When we need to update the aggregate state via domain event as part of a flow

• When we need to update the aggregate state via command (UI)

• When we have an aggregate with complex logic

• When we don’t want to create a new aggregate

When will we consider creating a new View microservice?

• When we have a new not finalized business requirement that isn’t mapped well to an aggregate.

• When we find ourselves aggregating 2 or more data types in the frontend/apigateway/other service for a specific UI component

• When we want to implement a specific complex business logic related to some main entity in our system.

• We will create a new view service for every new product functional requirement.

When will we consider aggregating data from 2 services in the apigateway ?

• When we find the need to aggregate 2 or more data types for a specific UI component

• When we need to manage a process for changing several microservices together.

• Implementing data aggregation or enrichment in the apigateway was done in the wild-wild-west and we need to stop doing this and moving to view-services.

• When the 2 services are related to the same Bounded-Context.

When will we consider having persistency on View microservice ?

• Every view service should have persistency as default implementation.

• Only if the user needs to change the data state

• When the view-service represents a new data state based on other aggregates domain events (e.g: feeds) and we need the historical data

• When we want to boost the performance of our application using cache / building read optimized data

When will we consider creating a new Cross-Cutting microservice?

• When we have a new business requirement that isn’t mapped well to an aggregate.

• When we find some business logic is repeatedly implemented in many services.

• When we have a new repeating functionality that contains no business logic.

• When we have a business requirement that must be implemented across many aggregates.

When will we prefer to implement a Cross-Cutting microservice (over implementing a shared library)?

• When the functionality is short and simple to implement, we will usually prefer a microservice.

• When we require persistence it’s usually a good indication to prefer a microservice.

• When we provide a simple wrapper that communicates with a 3rd party service.

• When we have some complicated business rules involved in the  business logic.

What are some good candidates for Cross-Cutting microservices?

• An SMS notification service

• A shopping cart service

• An Authentication service

• A user management and authorization service

Which type of communications are “allowed”?

• aggregate->(command)->cross-cutting

  ,

  aggregate->(domain-event)->aggregate

• view-service->(query)->aggregate

  ,

  cross-cutting->(command)->aggregate

• aggregate->(domain-event)-aggregate

  ,

  user/client->(command)->view-service

• aggregate->(service-request)->cross-cutting

  ,

  aggregate->(domain-event)-aggregate