Rates as independent microservice

[kabl]

Why the Rates service is (at build time) technical bound to all other / very specific ICO services? Why Rates service is not designed to be used in other projects (which not share same monitor or backend)?

    compile project(':commons:model')
    compile project(':commons:sql-repository')

These libraries have the entire Model and DB Entities inside which are not relevant for Rates. Even Rates DB Entities are in these libraries which are not relevant for the other services. E.g. Rates does not need to know about KycInfo.java and many other classes.

A microservice should not know about how an other microservice is persisting data.
Proposal:

• Isolate rates from code sharing which is not needed. Especially on DB level you should not share Tables.
• Keep Rates as independent Service. At code level and runtime
• One Rates instance/deployment could be used by several ICOs.
• Rates in a separate GIT Repo with own life cycle.
• Rates could theoretical even use an own DB.

http://microservices.io/i/Microservice_Architecture.png

[gsmachado]

Hello @kabl

Good feedback. We are planning to split the commons:model and commons:sql-repository, and move the parts to modules which are closely related to each other. Thanks!

However, suggestions like "Rates in a separate GIT Repo with own life cycle" and "Rates could theoretical even use an own DB" will not be done as a priority in the near future. But we are accepting pull requests! :-) :-) :-)