RPC for retrieving data and messaging to express intentions (commands) and provide integrations/side effects (events).
There are two ways to decompose and integrate distributed systems. One is easy, and the other one is better. The easy way to do things is orchestrated or declarative. The basic idea of an orchestrated system is that one entity tells another entity what to do. The other way to organize your services is through choreography and/or reactivity. Choreography solves the problems we face in declarative systems, like high coupling and low cohesion.
Changes in downstream services may not disrupt upstream services.
Messaging De-duplicator and Re-sequencer, and Distributed Transactions are some heritages from declarative systems and/or from Business Capability Decomposition. In this case, each Entity is represented by only one model for all services, which requires Distributed Transactions and blocking requests to deal with "transactional information between bounded contexts";
On the other hand, one of the main characteristics of subdomain decomposition (DDD) is autonomy, where each Aggregate detains all entities it needs to respond in isolation for each side-effect (business facts/domain events);
Reactive DDD (Domain-Driven Design) is an approach to software development that combines principles from Domain-Driven Design and Reactive Programming to build highly extensible, scalable, and resilient systems. Reactive DDD focuses on modeling the domain's behavior in distributed, event-driven, inherently reactive systems.
Subdomain decomposition is an essential part of DDD, and in Reactive DDD, the subdomains are decomposed to support Choreographed event-driven architectures. Each subdomain is responsible for managing its own state, and changes to that state are communicated through events.
Event-Sourcing is the most efficient/appropriate persistence strategy here, given the eventual nature of the design.
In an eventual and unpredictable environment about when an event occurs, how often the broker will deliver it, and in what order the subscriber will process it, Reactive DDD can help ensure that the system remains responsive and resilient by modeling such "uncertainties."
By modeling the domain as a set of reactive components that communicate through events, the system can be designed to handle large volumes of requests, maintain consistency and reliability, and gracefully recover from failures.
Reactive DDD is a modern and trendy approach becoming increasingly popular for building complex distributed systems. It provides a way to decompose a domain into smaller, more manageable pieces and design them to support a reactive architecture. This can lead to more responsive, scalable, and resilient systems and can better handle the demands of an eventual environment.
If you're interested in modeling uncertainty with Reactive Domain-Driven Design (DDD), here are a few resources that might be helpful:
