The second part of the post discusses supportive services. Supportive services support (as the name implies) business microservices. Moreover, they can be used to build an efficient and not boring environment, by avoiding implementing the same thing several times. Samples are given which can be implemented as supportive services. In the end stands a proposal with a large BUT in it, because there is no one answer to everything in programming.
Last time I talked about how microservices can be tailored along a business process (see https://annegretsarchitecture.blog/2018/03/08/how-to-tailor-microservices/).
But there are things still open: Supportive Services. We all know that we have to fight often same things: Search for an object, Publishing or even Reporting. Those “things” are not really business process steps – as explained earlier – they support the business process. A vacuum cleaner wouldn’t clean my living room by itself. But it is supporting me doing so. In the same manner, supporting services support the business services. Because supporting services are not specific to a business problem, they can be used almost everywhere. There are even services which are available over the internet and which haven’t to be implemented and operated by your own. I think, your manager loves those supporting services.
Let us go a little bit deeper into the services. What do we have to implement all the time?
- Searching
- Publishing
- Approval
- Reporting
Searching
Searching means here the search for a particular business object. The business object in our sample are bids, call of bids, and contractors. All of those can be searched for by particular attributes e.g. a name or by a full text search. Therefore, it makes sense to implement the search not separately. We implement a service which does the search even over different services. The search for bids has to search over the create bid service, the evaluating, and the awarding service. The search can be implemented that the search object and the search target is given to the service. E.g. when I know that I need only awarded bids, then I search only over Awarding.
It might happen that I need a search over all three services in question. In those cases, we can use the reporting service for a better performance or it is sufficient to deliver first the results of the first microservice and then to load the rest in the background. Anyhow the lazy loading we should do anyhow.
Reporting
Besides the searching over several microservices – which is seldom after my experience – we often need a reporting over several business service steps. If I am an engineer in the process, I want to see all call of papers I created, even though they might be already awarded. I use this report as entry point of my work – as some kind of inbox for example. For those reasons we need some kind of reporting. The reporting is done on a separated data storage (data lake), which allows to organize the data in a manner that pre-defined reports can be delivered to the client in question. That means, we can create reports on contractors and how they answer to call of bids or even some kind of tasks list for the awarding manager.
Publishing
Publishing is quite obvious point. We need a publishing for call of paper (when it goes from the Draft status to the Sent status) and we need it for the bid (again Draft to Sent status). Both publishing ways need probably some kind of Approval workflow, which is another supporting service.
Approval
The approval workflow can be defined on call of bids, bids, and awarding (and probably on some intermediate states). We can define the approval workflow independent from the business object to be approved, but we need to define the transition of the business object. So, the service gets the business object reference, the approver (probably automatically found by a search service), and the transition (Draft to Sent) to be approved. More is not necessary, and we can reuse a lot.
Conclusion
This are only some samples of supportive services and how they can be used. Another sample might be a signature service for a contract, which is even done on the outside of your own company and their services. The supportive services allow to avoid double implementation and to use synergies.
BUT – of course there is always such a but in capitals. You might increase the dependencies between your services, when you use those supportive services too heavily. E.g. you might be always forced to change the search service, because the system grows constantly, and every new service wants to use the search service in a specific manner. Please look at those cases critically. In question decide for the implementation inside of the business service and not for the supportive service. The independence of services and teams is definitely a higher good then to reuse something, at least in my opinion.
In the end, you have to balance out using of synergies and independence. The answer to that is not easy to give and has to be questioned every day anew.
ANNEGRET'S ARCHITECTURE 