I'm looking forward to getting a great project, and on its own scale I've suggested adopting a service-oriented architecture - because it is easier to solve several average problems than a very large one. I was asked about the database: that even if the application is divided into modular components, the bank should be designed a priori . This sounded strange to me, but from my lack of experience with this paradigm I could not argue about it.
It is my understanding that each service should be tightly coupled ( loosely coupled ) to justify this approach. And my common sense says that - if it's not docked - it does not have to be on the same bank, even though it makes it easier to grow in scale (putting each subsystem on a different server, for example). This implies, of course, to lose some of the referential integrity - because in the few points where one subsystem interacts with another, we have entities in common between them. In my opinion, this is not a big problem, but this is the main concern of those who questioned me, insisting that only with a unified database can the data consistency be maintained.
Which of these two approaches is most common in systems that follow SOA? Because? And how the problem is resolved:
- of the data consistency, if the response is "distributed"?
- of modularization / growth in scale, if the answer is "centralized"?