Font size
WorksheetsPractical Architecture - DDD
Total questions: 12
Worksheet time: 24mins
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
When sending a domain event..
We should understand which services might consume the event
We should send it only if there is at least one consumer
We shouldn't care about other current/future consumers
We need to add as much as data to the payload to avoid future querying
Which type of data should we send in the domain event payload?
The more information we add on what happens the better
Only the domain event “identifiers” e.g. timestamp, what happened, id’s for reference etc
Depends on the consumers of the event
Only immutable data
