SERVICE | Transactions |
BUSINESS REQUIREMENTS | Manage transactions and bills information |
FUNCTIONAL | Import transactions file, list transactions report, register bills, acknowledge transactions, monthly summary comparison report |
DATA ENTITIES | Transactions, bills |
DATA AUTONOMY | None |
Stephan van Hulst wrote:You divided your services based on technical capabilities, not based on business objects. As a result, your services are not so loosely coupled as you might initially think.
Stephan van Hulst wrote:For instance, what will happen when the nature of a transaction changes? It's very likely that not only does the upload service have to change, but the query service as well, and if you're really unlucky, the acknowledgement service as well.
Services in a microservice architecture are responsible for their own relatively self-contained bit of business. Of course it's possible that one service depends on another, but if the business of one service changes, it should not send out big ripples across your entire architecture.
At the very least, I'd merge your upload and query services into one: a service that's responsible for the storage and retrieval of transactions. It makes no sense to keep those two separate.
The service that handles acknowledgement could be separate if you want it to. Inside your imaginary company, you can sort of picture it as a separate unit of bean counters that just go into the archives and rubber stamp transactions that are already there, or check whether a transaction has been stamped, without really caring how the transaction ended up in the archive.
I think you're making a mistake by putting the acknowledgements and the transactions into separate databases though. While it will work, you're denying yourself an important layer of security: Your DBMS will not be able to enforce referential integrity between the transactions and their acknowledgements.
Ron McLeod wrote:I don't see the value of breaking-apart the various aspects of a Financial Transaction Logging Service into smaller pieces.
Ron McLeod wrote:In the real world, I wouldn't expect a financial organization to have separate departments/business-units for uploading, querying, reporting, and acknowledging transaction information.
Ron McLeod wrote:
Claude Moore wrote:I suggest you to have a look at Microservices Patterns by Chris Richardson ...
He has been featured at a lot of conferences and in video/audio podcasts - you can find a good number of them on Youtube.
I've also really enjoyed video courses from Memi Lavi - his focus in on architecture rather than design and implementation. I've gone through a number of his courses on Udemy. The standard prices on Udemy seem a bit high to me (especially if you are paying for them on your own), but if you subscribe the mailing list, they will send you offers every couple of weeks to purchase courses for around $12 each.
Claude Moore wrote:I suggest you to have a look at Microservices Patterns by Chris Richardson. The book discusses in depth patterns presented on author's website and it's very well written.
Examples are in Spring Boot.
Stan Belen wrote:is it okay if I'll create a public github project for the purpose
Junilu Lacar wrote:That is an excellent idea. And yes, I'm saying that you would test-drive the refactoring of the code.
Junilu Lacar wrote:
Stan Belen wrote:How can I restructure this code to be able to unit test it?
Ironically, you'd write a unit test that would show you the ideal structure of the code so that it can be tested in isolation.
Let's see how you react to this first before I explain further.
Junilu Lacar wrote:When something is difficult to test, you refactor it so that it's easy to test.
Junilu Lacar wrote:Mixing in a API call inside a method like updateAddress seems like a poor choice. I would separate those two concerns.