Hi Andras,
Ideally the following should happen.
The Customer should be created before the checkout.
A Checkout can happen on a cart - the cart needs a Quote and a Quote needs a Customer.
Can this relationship be broken?
Technically - Yes.
But it is always good to follow this Architectural principle.
As you rote above, detailed information may not be captured before the check out. (This will depend on the complexity of the offer and the possibility of a customer hierarchy).
Please refer to Product Order Open API622. That can be taken as a reference for the customer data that is needed before the order is submitted.
And the tasks that you mentioned are all valid.
Based on the complexity and diversity of the offers the Orchestrator may trigger a lot more tasks and that is where the Open APIs 636, 640, 641, 638,639 etc may come into the picture.
And some of these may need to be triggered more than once in the same order instance.
Is it mandatory to have a separate function as an orchestrator?
Please analyze your process for every Product offer class / category, check if the above mentioned APIs will need to be triggered or only a subset of them are to be triggered. This can be one criterion.
Likewise your functional Architecture around Customer and Billing Account management is another criterion.
Hope this helps.
Regards,
Jag
------------------------------
Sri Jagadish Baddukonda
CSGI
------------------------------
Original Message:
Sent: Mar 25, 2021 11:09
From: András Door
Subject: Customer creation through an order
Dear All,
I'd like to consult about creation of a greenfield customer: my focus is on how entities should be created when a new customer entity is created at the end of a checkout.
Suppose having a checkout flow resulting in an Order created in the Order Management. During checkout proper customer data are on hand, so at the end of checkout valid Order, Customer, Customer Account and Billing Account entites can and need to be created. I can see three main patterns to the parallel entity creation:
- Order Management orchestrates entity creation, it's responsibility to create customer related entities in Customer Management.
- BFF creates the entities first and later creates the order with the references to the other entities
- An orchestrator component should be created in the backend layer to receive all data from BFF and create the entities in Customer Management and Order Management as well.
I'd say it's an interesting question, because from clear microservice architecture point of view implementing a separate orchestrator (3) might be adviseable. However, implementing and maintaining a standalone component just for such a small process might be treated as overkill. Delegating this responsibility (and business logic) to BFF (2) seems not the correct way, because exactly the same flow needs to be implemented in all the BFFs realizing a similar business process. So from practical aspects I'd say that Order Management might be the most approrirate (or less dirty) solution in this case, but it's also not most beautiful implementation ever.
What do you think? I would really welcome your opinion.
Thanks you,
------------------------------
András Door
------------------------------