5
I’m with the prospect of taking on a big project, and by its own scale I suggested the adoption of a service-oriented architecture - because it is easier to solve several medium problems than a very large one. I was asked about the database: that even if the application is divided into modular components, the database should be designed whole a priori. That sounded strange, but due to my lack of experience with this paradigm I could not argue about.
It is my understanding that every service should be little coupled (loosely Coupled) others to justify this approach. And my common sense says that - if it’s not coupled - it doesn’t have to be in the same bank, even though it’s easier to scale (put each subsystem on a different server, for example).
This implies, of course, losing some of the referential integrity - because in the few points where one subsystem interacts with another, we have common entities among 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 consistency of the data be maintained.
Which of these two approaches is the most common in systems that follow the SOA? Why? And how is the problem solved:
- data consistency, if the answer is "distributed"?
- modularization/scale growth, if the response is "centralised"?
When I say "distributed," I don’t mean necessarily to them being on separate bases. For example, if table A is not directly or indirectly linked to table B, then it does not matter whether they are on the same basis or not. On the other hand, if A has a foreign key for B, then they need to be on the same basis - even if the services that access them are capable of doing each other’s work in isolation. From what I understand of your answer, it is irrelevant whether it is modeled in one way or another, because there is a layer of abstraction between the service and the data it accesses. That’s it?
– mgibsonbr
Exact. This layer facilitates the change of basis, not only for changes of provider (i.e.: exchange Mysql for Oracle) but to change the environment (make the code point to the base of tests or production easily and on demand). If you abstract the bank, the services do not need to know whether it is distributed or not. Hence you model it without headaches.
– Oralista de Sistemas
In time: modern banks are made to work very well in cluster - if you consider this a form of distribution!
– Oralista de Sistemas
I agree with Renan that the bank should be abstracted. The issue of distribution in this case is more "functional" (or "property") than storage and normalization. Saying that services are isolated has more the sense that they are self-sufficient (if a service returns a customer code, for example, it is an internal code his - regardless of whether the caller stores this value or not). By the way, it will probably be easier to understand and discuss if you provide a simple example of the problem domain.
– Luiz Vieira
@Luizvieira I can’t give examples, because the project is still in the "polling" phase. What I have is a list of comprehensiveness (like: "Management of Construction Sites", "Management of Contractors and Measurements", "Environmental Management", etc.) which - in my opinion - correspond to sub-systems with a high degree of independence between them. Although they refer to a common real-world entity (e.g.: a work) I understand that every form of integration between services should be given exclusively via its service interface, without exposing internal details (e.g.: id of the work in the comic book).
– mgibsonbr
Anyway, I’m satisfied with that answer. After digesting the information a little, especially in the light of this last example (because I must think about a service no matter if it is external or internal, is not this the idea of SOA?), I believe I have found the solution to my doubts.
– mgibsonbr