This blog post provides guidance on mapping process requirements to implementation components with the Orchex Enterprise Orchestration Engine (EOE).
Update 15.Dec.2025: After years of frustration with WordPress, I am finally abandoning this blog. The content will likely stay here for some time, but new content will appear here:
One goal of an EOE is to support domain-driven design (DDD):
Rather than focusing on vendor-specific webservice APIs and process implementation details, implement orchestration processes per your organization’s logical requirements, and then construct the orchestration process to invoke the vendor webservice APIs as required to meet those objectives.
When defining an orchestration process, you can start from the beginning of the process (what are the inputs, what needs to be done, what needs to be returned), or start from the end (what needs to be returned, what needs to be done to achieve that, what data is needed as input).
I recommend starting from the end. Focus on the output payload that you need to generate and the orchestration processor that you need to invoke to achieve that. Determine its requirements, whether on a webservice API or other processors its input payload or some combination of these. Do the same for any processors on which the primary processor has dependencies. Work backwards to define the orchestration process flow.
Then, map requirements to vendor-specific webservice APIs and call sequences.
Then, determine any JSON transformations or other logic required to achieve those goals.
Map these requirements to individual processors and LogicBlocks.
When possible, use the payload to make processors reusable, unless you know that a processor serves only one purpose).
From this, determine the input payload.
deliverystack.net 