We're developing a total solution, and we've chosen service-oriented architecture to loosen subsystems. However, now we have a problem.
When customer orders something, Order Subsystem is responsible to get that order, and register it. However, there are some other modules which are responsible too, in order registration process, and each module should do something on it:
- Customer Accounting module should check customer's balance, and prevent order registration if there is not enough money in customer's account.
- Asset Management module should increase/decrease customer's assets
- Rule Engine should apply some business rules dynamically on it (like preventing a specific customer, or notifying an operator, etc.)
- CRM should view customer's history, and give good customers some discount
- ...
Right now, we're doing it this way:
public void RegisterOrder(Order order) { RuleEngineService.ApplyBusinessRules(order); // some code here CrmService.GiveDiscountIfApplicable(order); // some code here CustomerAccountingService.CheckBalance(order); // some code here AssetManagementService.ChangeAssetCount(order); // some code here } This means that if we add another subsystem (module) that needs to do something on order, we have to recompile the code of our OMS (Order Management System) to support it. Also we're coupled to some extent to other subsystems here, and if one of them fail, this registration process fails.
One way of making this piece of code dynamic and loosely coupled is to use interfaces or contracts, like:
public void RegisterOrder(Order order) { // Finding a list of all IOrderProcessors. // Looping over each, calling orderProcessor.Process(order); } However, it has two problems:
- We can't use interfaces over SOAP and HTTP (we don't have access to other subsystems' DLL files)
- Those need to run in a specified order (rule engine the first one)
What should we do here? What are the known patterns and practices?
