This is a summary of some of the vocabulary we’ve been using to think about the Commerce Coordinator.
Types of connections in Commerce Coordinator, and which file they should be put in.
Purchase Action Flow (or just Purchase Flow)
Definition: A sequence and record of Actions for a purchase.
One purchase can start many Purchase Flows.
The output of one Action in a Purchase Flow may be required for the input of the next Action in a Purchase Flow.
Internal Connections (defined later) are what connect one Action in the Purchase Flow sequence to the next Action in the Purchase Flow sequence.
Definition: Independently deployed software that performs an Action in a Purchase Flow.
A Purchase Flow triggers one or more Services to perform Actions in a certain sequence.
A Service can offer and implement the same Action.
Services that are part of Open edX are an Open edX Service.
Services that are not part of Open edX are a Third Party Service.
Definition: The implementation of an Action for a Service.
Example: Different Services can implement the same Action. (Credit Card Processor 1, Credit Card Processor 2…)
Action Implementations must do the same thing and accept/produce compatible input/outputs as other Action Implementations for the same Action.
Commerce Coordinator (or just the Coordinator)
Definition: A Django IDA that connects Services to perform Actions in a Purchase Flow.
The Coordinator connects:
The Coordinator generally does not connect Open edX Services to other Open edX Services. There are other better ways to do that.
Plugin (sometimes called by its old term, a Component)
Incoming External Connection
Definition: A way to start an Action in another Plugin.
Is part of a Purchase Flow.
Open question: Where should the definition of an Internal Connection be stored?
Open question: What will be the “minimum definition” for all Internal Connections in general?
Open question: What will be the “minimum definition” for all Internal Connections in a Purchase Flow?
Outgoing External Connection
Transition-to-Coordinator Waffle Flags
Transition-to-Plugin Waffle Flags
This is an example of a couple of the technical glossary’s terms:
Example of a GET of Order History.
Add an example of an entire Purchase Action Flow using vocabulary of the glossary upfront
Add specific examples for key glossary items (e.g., of an Action)
Go back and make ADRs and other documents consistent with this glossary.
Note: Essentially, our signal configuration is a list of subscribers to topics. In Commerce Coordinator, the subscribers are methods in Plugins, and the topics are Incoming Connections/Signals.
Still need: Traceability, storage/auditing, replayability
Note: Need to investigate having Commerce Coordinator be a message bus to message bus
Add Receiver for Signals & Pipeline Steps for Filters