Skip to content

Latest commit

 

History

History
35 lines (23 loc) · 1.29 KB

002.md

File metadata and controls

35 lines (23 loc) · 1.29 KB

Inter-module communication

Status

Accepted.

Context

  1. Three independent subdomains (Catalog, Showtimes, Ratings) emerged during an Event Storming session
  2. Ratings and Showtimes modules depend logically on events from Catalog
  3. It should be easy to develop each module without need of changing another.
  4. Modules should be independent from one another in runtime.
  5. It is possible that some of these modules might need to be separate deployment units in the future, due to different scalability needs (some might be used more often than others).

Decision

Architecture will follow an event-driven architecture pattern. All inter-module communication will be asynchronous and through an event bus.

For the sake of development speed, until app is actually deployed to an environment, an in-memory event bus will be used.

Consequences

Pros:

  • Modules independence (in runtime and development)
  • Failure resilience

Cons:

  • Event broker maintenance
  • Event contracts complexity
  • Idempotence when consuming is a must (due to potentially duplicated events)
  • Data duplication

Considered alternatives

Integration via database, especially in case of read models (read model would query database for write-side data from another module). That would introduce too much coupling in development.