I think that taxInvoice2 should not implement taxInvoice1, that is, I don’t think that the service that comes to solve the problem should refer to the one that specifies it.
This is because, if so, it would not be possible to replace the taxInvoice1 service.
I think that I have not extended myself enough before, sorry.
The idea behind microservices is that they can be seen like black boxes, we don’t need to know anything about them, only use them using his API’s.
I would specify a service using the following components:
Container: Specifies the container where the service runs, microarchitecture, entry point and filesystem (DAG?), and environment variables.
Api: Defines how you can interact with the service, the ports where it listens, the communication protocols that it supports, methods and the different errors and responses that it can give.
Perhaps also the cost that the use of each method can have (but for now it is to complicate it a lot …)
Dependencies (optional): Services that it will use during its execution, so the node can mount them during its assembly.
Tensor (optional): Defines “intelligence” that the service can provide, I think it would be a description of a polynomial (without coefficients and describing the variables).
Ledger (optional): Defines the database used by the service, as we speak of a decentralized network at all times, this data must be contained in a blockchain or something similar. I think it would be a class diagram and a consensus algorithm.
The last two are maybe a bit crazy (yes, brainstorming necessary …).
With that said, I am going to use an example to expose why I see necessary design IPSS.
Let me change your example to a somewhat more complex problem, ordering a set of integers. You will agree with me if I say that it is not easy to find the ideal implementation of the ideal ordering algorithm.
Yes, someone could develop a powerful and well optimized algorithm and say that it is the best sort algorithm that will ever exist. But no matter how competent your implementation may be, you may be wrong, there will always be someone who comes up with a better solution at some point.
And it is not only that, but there could be some implementations that serve better in one type of scenario and others in others, therefore the statement of our developer is quite bold.
Therefore, we would like to have a system that, without a central axis, allows us to always choose the best way to solve a problem or perform a task.
The various services that we could have regarding the problem of ordering integers would be:
A service that implements a bubble sort.
A service that implements a selection sort.
A service that implements an insertion sort.
A service that classifies ordering services through linear regression, randomly generating the entries. It can export what it has learned using a tensor. Its api allows you to add sorting services, order the tensioner and command it to train.
A service that classifies management services by scoring who performs the least time. It can export what it has learned using a tensor. Its api allows you to add sorting services, order the tensioner and command it to train.
A service that uses the same type of tensioner and solves the problem. Its api accepts, like the sorting algorithms, a list of integers and returns the ordered list.
I believe that this architecture allows decentralized development and allows the best integer ordering algorithm to be used, even as a function of input data or available response time.
I hope I have explained myself enough.