Working on an ecommerce project whereby a PHP application (back-end & non-customer facing) is currently responsible for processing an order from checkout stage through to generating profit/loss reports, processing the order and also performing various algorithms on behalf of a data science team.The algorithmic components will be extracted out to a separate application (python).PHP will be sending a json payload via curl through to a python application end-point / passing the payload over to a beanstalk queue or similar. However there is mixed opinion relating to which application is responsible for what.The python developer wishes for the PHP dev to prepare and send over a large payload (qty, order value, user demographics etc.). Basically everything that the python developer requires in order to perform their algorithms.The Php developer believes that all the python service requires is the order_id and from this, it can mine all the information it needs to run whatever algorithms it requires from the database. The php developer further argues, that if it is doing all the preparation of the data, then it may as well run the algorithms too as the passing responsibility to the service becomes redundant as much of the work has already been done.Is there a right or wrong choice? could somebody provide any decent arguments for both sides to consider? Could anybody recommend any resources to assist in understanding of internal service oriented architecture?
Service Oriented Architecture - Component Responsibility
web services;soa;single responsibility
If the front end is made responsible for the 'large payload' for the processing by the Python back-end then you have a high degree of implementation coupling between the two systems that means maintenance, change management, or refactoring becomes more complex as both sides of the communication require significant interdependent re-engineeering in order to deal with the sending and receiving of the data.In addition, implicitly, a new data store is being created in the transmission protocols (albeit transitory) as the data is formatted by the front end, transmitted, and parsed by the back-end.By sending only the index into the data in the database you remove the issue of strong coupling and changes to either end of the process may take place with (usually) little dependence on the other side. You also have fewer places for errors to creep in because there is no formatting of large messages and then the parsing of those messages. In addition you have easy scalability because in future you would be able to add more front-end processing and more back-end processing without being concerned about which front-ends connect to which back-ends (that's all handled by the back-ends reading from a common data store).This assumes you have, and will continue to have, direct access to the database by both systems i.e. that you're not planning to relocate either sides of the dialogue to remove systems in the future. If you relocate one of the systems away from direct connectivity to the database in future thenOf course the issues of sending large messages like this are manageable (for some systems there is no direct access to a shared database) but they add a layer of complexity that it appears you don't need to consider.