Introduction
Picture shows a page displayed to a user, that is composed of widgets from different services.
System is divided into separate services. Each service has its own data within its own database (or database schema), and can perform operations on this data. There is no data duplication between services - ie. customer's name is only in one service and no other service knows it. This results in conclusion that when comes to displaying data to a user, the service itself must render its data, because it's the only one that knows the values that should be displayed.
Services can't have references to each other, so they communicate asynchronously by messaging, for example via queues. When a user wants to perform some action, the command is sent to a specific service, and after handling this command, service publishes an event (or events) saying that some action has just took place in a system.
Within service boundaries components can communicate in any way, for example via rpc - a web client component of one service can make direct ajax calls to a server component of the same service.
After completing handling a command, the only data that can be published is composed of identificators, statuses and dates. Of course data send in a command can contain any information appropriate for a handling service - that is if its service boundaries contain customer's names, then a name can be send in a command, but if customer's names are not included in this service boundaries, than it can't be passed to this service within command.
Despite composing user interface in a different way, we still want to be able to:
- integrate data from separate services into tables
- perform actions that spans service boundaries in transactions
- perform crud actions with immediate response to a user
- manage cross-service validation on the client side
- communicate between services on the client side
- use caching efficiently
- compose ui without lots of server requests
- compose ui of view models, that are able to render themselves
- one component should provide some sort of grid for view models, where they can render themselves
- one component will be responsible for integrating services and providing configuration for them
Integration of services introduces cental point of dependency, that can bring us new problems. It has to know what actions from which services to call on a given requests and what data need to be passed, so in essence it needs to know a lot about services. If a service changes, this integration point also has to change, and this may leads to conflicts with other services.