|
|
|
|
|
|
by bjornjajajaja
2300 days ago
|
|
|
Hmm. I think it could work well. Thinking if Qt signals/slots mechanism but using database. If you have separate tables for publish subscribe (one writer multiple readers) it would be quick. And to be honest, the services are loosely coupled between each other that is a great benefit. It’s not a “spaghetti of services” because a good design will carefully consider them. Plus it could give some good benefits for auditing trails too and consistency in data storage/archiving. |
|
|
I don't want patterns where I have to be good. Anything is possible if you're good but how does the pattern help and protect the developer?
That said, as a developer, how do I know some data should be owned by one service or another? Should I notify other services when I change data? Where is the separation of concerns? Is the DAL a monolithic codebase that knows who to notify or what event to write when things are updated?
I like event queues but instead of using something like ZeroMQ they seem to suggest using a custom rolled table. If I want to add a new event listener such that I have more than one, do I have to know that at event write time and write n messages? Do I store message completion separate from the message itself? Does the DAL handle that by knowing who needs what? Aren't we back to thinking about all those service interactions but in the DAL? So much work is glossed over that I can only assume the author hasn't worked with queues or an ESB very much.
The ultimate question though is, why are these services even separate if they're mutating the same data? Just merge the services (or at least the operation in question) instead of rewriting the entire app. Way easier than orchestrating all of your systems through a monolithic DAL.