听课笔记：Advanced Distributed Systems Design Chapter 9
Advanced SOA
BUSINESS COMPONENTS
Services can be divided into Business Components (BCs). For example, a Sales service may be divided into Regular Customers Sales and Stategic Customers Sales. Similar to the boundaries of services, the boundaries of BCs should also be based on stable attributes, meaning that a regular customer is very unlikely to become a strategic customer, and a strategic customer is usually always a strategic one. The number of BCs in a service is commonly two, if a service ever needs to be divided. Any number greater than three is strongly advised against.
The division of the service into BCs should be self contained. Other services do not need to know about or be impacted by the division. After the creation of BCs, the only responsibility left at service level, should be the event contract that it exposes to other services.
AUTONOMOUS COMPONENTS
A Business Component is composed of one or more Autonomous Components. An Autonomous Component is responsible for one or more message types. It is composed of one or more message handlers and the rest of the layers in the service, and can be seen as an independent package (NuGet) .
A commn way of division of service/BCs is by systems. A service may cross multiple systems, each of them would have one or more ACs deployed.
COUPLING BETWEEN ACS
Don’t try to reuse code between ACs; Strive for “disposable” code; Solve for today’s problem – not tomorrow’s. The above guidance of building ACs goes the opposite direction to the popular belief of writing generic and reusable code. However it is in accordance with the principle of SOA, which keeps a low degree of coupling by finding the suitable boundaries of services, and by taking autonomy and single responsibility in components. With the benefit of decoupling, when business requirement changes developers can just re-write a component from scratch without breaking other services and components, instead of writing generic code for possible requirement changes in the future.
AUTONOMOUS COMPONENT DEPLOYMENT
ACs can be deployed with low physicial autonomy, where msg queue, server, DB and storage are shared with other ACs, or it can be deployed with its own resources if needed. If an AC is deployed with its own resources, there will be a direct link between the hardware, and the business section, as AC is designed to handle certain msg types(ideally one). The benefit from it is that it is easy to tell the cost for handling certain part of the business.
A question from an attendee: if we do not try to reuse code among ACs, wouldn't they be similar to stored procedures that are coupled to database tables?The answer is that SOA is not entity centric. There is not much of common entities shared among services. Instead, each service may own some attributes of an entity. The down side of stored procedures are largely due to coupling to other procedures, which would not be the case in ACs.
REPORTING
Reporting does not reflect business capability boundaries; hence it should not be made a service. Reporting is harder in SOA, as data is scattered in multiple services, but it can be done in a way that is not that different from composite UI grids.
For the type of reports that are generated repeatedly, a better way of reporting is to replace them with real time emails. The idea is that requirements are often not requirements, but workarounds. To generate a report is not a requirement; to get the information of value to users is. Identify the patterns users are looking for in reports. Model constants as domain concerns. Implement them as event correlations, and send emails when it happens.
For the ad hoc/research type of reports, there is not much SOA(or any systems) can do. This is because the user is trying to discover something new. There is no stable business extraction for that yet, which is what SOA is meant to implement. The reporting functionality can be put in IT/Ops which pulls data from services.
REFERENTIAL INTEGRITY
While relational database keeps single source of truth by foreign keys, the invert referenced (children to parent) data structure in SOA does not keep referential integrity by database operation. As different parts/attributes of a parent entiry are persisted separately in each service, the attributes may go out of sync among each other in database. However it is not that the traditional monolithtic systems do not have the issue of referential integrity. They do not allow out of sync data to be inserted into database, but data can go out of sync in process before they are persisted. On the other hand, a SOA system achieves eventual referential integrity by its re-try mechanism, as illustrated in Chapter 5.
For deleting data, you can delete "private" data without concerns about other services; however once the data is published, you cannot delete them. To discontinue it is a complex business process rather than simply remove it from database.
