Designing a microservices architecture with DDD | Is DDD still useful?

how can we design our microservices architecture using DDD are there other options let's Discover it in the next few minutes whether we are designing a new system or trying to decompose a monolith the main challenge is in our microservices architecture are the composing the system into services with 12 defined responsibilities and establishing how data is exchanged and kept consistent across such services proper microservice architecture design defines microservices which are Loosely coupled and highly cohesive low coupling means that macro services are as independent as possible in an idea scenario a microservice should be able to perform its duties without depending on other micro services our coeition means that each microservice is responsible for functions that are strongly related with each other what we are trying to avoid is building a distributed monolith this is a system where Services depend on each other thus cannot be developed or operated independently these systems are pointless as they pay the cost of microservices without getting any benefit from it for instance a distributed monolith is not elastic if we experience a spike of requests to microservice a but this microservice is highly rapid with BNC we will be forced to increase the number of replicas for all the three services now that we know coal sentries associated with our design the question is how would the compose our system into Services that's where domain-driven design comes into picture the first step is to elicit requirements and create a map of our domain that's the domain model in the early stages of our design we need to keep the model lean there is no need to create a detailed class diagram we need to be able to iterate quickly through different options and ideas it's important to contrast and compare we can Define major entities constraint and most importantly their associations associations are key to identify potential boundaries these boundaries could represent Aggregates or most importantly abounded contest these are areas of the domain that exhibit High Collision within the boundary and low coupling with the other contests those are exactly the properties of a well-defined microservice architecture we have derived a very important concept A microservice is equivalent to a bounded context in domain-driven design now that we have identified our microservices we can split the work involve other Architects or other teams so that they will add more details to their subdomain the next challenge is defining how data is exchanged between microservices and most importantly how it's kept consistent despite all our efforts to isolate subdomains there will always be some relationship between Services which we can see clearly in the domain contest map an order contains data from multiple domains like the product catalog declines account and the logistics since each microservice manages its own independent database we cannot leverage foreign keys to map these relationships so how can we combine data from multiple domains and most importantly how can we keep it consistent that's where things get complicated one approach is what we already see on screen we link the different subdomains through the identifiers of their entities as we learned from the DDD the identity is constant for the entire life cycle of an entity thus it's a low maintenance relationship once we link on order to a package through their identifiers we will never have to update the relationship because the ideas never change if we included the package status right within the order we would be forced to synchronize the data between the logistics service and the order service anytime we have a status update however an end user wants to visualize all the data when it's seeing on order how can we reconstruct it if all we are doing is aggregating data and not business logic we can expose separate apis for each sub-domain and shift the aggregation responsibility on the clients we can optimize this approach by introducing an API Gateway that Aggregates the data for the clients this way we deal with the complexity of aggregation only once another common approach is to have a microservice communicate with other services over restful apis or RPC however this approach increases coupling between services and creates explicit dependencies the resiliency of the order service is dependent on the resiliency of the logistics service thus we are forced to implement retries circuit breakers and other complicated patterns from an implementation perspective if we want to update the logistics interface we need to do it in a Backward Compatible way otherwise we are forced to update the logistics and or their services at the same time this is when our system quickly turns into a distributed monolith because a lot of coordination is needed between the different sub-domains and the teams that maintain them that said it's not always possible to aggregate data in the higher layers of our system there are scenarios where to implement a business rule we need data from another domain and we cannot leak business logic in the presentation layer in this scenarios we can use events and materialize views in this scenario data is replicated asynchronously over events any microservice interested in a particular event can subscribe to our topic and keep a materialized view of the portion of data that is of interest in the particular subdomain the logistics service can generate an event when a package is delivered the order service can mark the order is completed while the notification service could send an email to inform the user event driven system minimize the coupling between the different Services however we pay the price in terms of observability and data duplication the system are also more difficult to implement and less intuitive even for Architects that said can we combine events with DDD that's a question for another video if you want me to cover the argument leave me a comment in the section Below in the meantime if you want to know more about microservices or DDD watch one of these videos you if you enjoyed the content like And subscribe and see you next time

Channel: Marco Lenzo

Views: 23,230

Keywords: microservices, microservices and domain driven design, microservices architecture, microservice architecture, microservices and ddd, microservices and events, microservices event-driven, microservices orchestration, microservices choreography

Id: gtZIaSxRkS4

Length: 7min 39sec (459 seconds)

Published: Mon Feb 20 2023