📄️ Chaine's Architecture
At chaine, we are using a combination of Domain Driven Design, CQRS and Event Sourcing.
📄️ Autonomous services
To go fast and not break things, we need resilient services. We need services that continue to function when related upstream and downstream services cannot. We want teams to be confident that an honest human error on their part will not incapacitate the system as a whole. At the same time, we need to keep the overall complexity of the system in check. Simple is always better. We want to compose our systems from simple and repeatable building blocks that we snap together. We want the system to naturally evolve by simplfy adding and removing uncoupled services.
📄️ External Service Gateways
An external service gateway is one of the three pillars of a subsystem (1. Control Service, 2. Backend for Front-end or BFF, and 3. ESG). The ESG pattern works at the boundary of the system to provide an anti-corruption layer that encapsulates the details of interacting with other systems, such as third-party, legacy, and sister subsystems. These ESG services act as a bridge to exchange events with the external systems. External systems are owned by a differen "organization". This may be another organization in your company or another company altogether. The implication is that we have little to no control over the design and architecture of these systems. Nor do we have much say over when and how they might change. THis means it is in our best interest to isolate the interactions iwth external systems, to protect the rest of our system and allow each to change independently.
📄️ Definitions
Trigger
📄️ Trigger and listener functions
Author's general definition under Functions section:
📄️ ESG Gateway
The nomenclature we're using for the esg that is responsible for controlling the flow of events in and out of a subsystem is $-esg-gateway (i.e. jedi-esg-gateway). This means that this is the esg that is responsible for controlling flow of events "internally" in Chaine; with other subsystems.
📄️ What is the pipes and filters design pattern?
The pipes and filters design pattern is a way to process data or perform actions on data by breaking the process down into smaller, independent steps, or "filters." These filters are connected together using "pipes," which pass the data from one filter to the next in the sequence.