Distributed Systems using DDD
A Distributed System is a system of several processes running on different machines, communicating with each other through the network, and are sharing a state or are working together to achieve a common goal.
Distributed Systems are often required to develop complex systems that need to keep evolving. A common problem distributing the business logic across applications is the tendency to create a lack of a shared understanding of the domain which costs days of developer time, integration problems, and risky production deployments.
Domain Driven Development (DDD) helps an organisation to gain a shared understanding of the domain the software describes, isolating them so that a number of team can keep supporting the domain without relaying on specific person availability.
The DDD design is intended to help human beings t understand the product, and communicate about it.
Distributed Systems
One of the challenges faced in Distributed System is the difficulty of implement transaction across multiple components and APIs.
Aggregates provide good guidance to design a Domain model that focus on transactional boundaries within the system.
Service APIs should be designed to map to an action on an aggregate, which maps to end users mental model. So a ‘service api’, can be thought of as a set of operations, each being a command to an aggregate. Each Service API is transactional.
Bounded Contexts are used to identify a broader grouping of Service APIs. A bounded context or a subdomain may have multiple aggregates.
Eventual consistency
Messaging allows to implement eventual consistency without the need for a global coordination. To achieve eventual consistency we can employ one of the following protocols:
Two Phase Commit (2PC)
CQRS
CQRS (Command Query Responsibility Segregation) can be used to divide Services in:
Services APIs that perform write actions to an aggregate
Services APIs that perform read queries to an aggregate.
Event Sourcing
Event Sourced System maintains application state as series of events, instead of directly updating and aggregate state. These events can be re-played anytime to recreate state. This can add some complexity to the system, but has many advantages for recovery, playback, rollback, auditing, system evolution, etc. Event sourcing can be implemented having Services APIs publishing business events that perform write actions to an aggregate.
Reactive System
Reactive Systems can be implemented to make the system responsive, resilient, elastic, and message driven.
Last updated