So understanding of events should be the inner module understanding. Then you can have granular events as much you need.
But if you try to use those events as they are also for cross-module integration then you'll have a leaking abstraction and first step to distributed monolith. Which has all the cons of monolith and all cons of microservices - without pros ;)
or through e.g. some external message bus as Kafka, RabbitMQ etc.
In general command send with pub/sub semantic - so you're publishing command and expecting to get event at some point with success or failure.
I'm not sure about your particular business case, so it's hard to suggest you which would be the best for you. But imho starting with proper boundaries, load analysis etc. is always good starting point ;)
I appologize for a lecture :P
Feel free to ask more questions if that wasn't clear answer ;)
No, no need to apologize this has been wonderful and I appreciate your time spent on me. I feel like I've become a struggling student that sat down with a professor :p I was not even aware that a microservice lives in its own process and spun up with docker or even systemd
I got few scars on that by myself :D
I think that microservice doesn't have to be on docker
it could be a set of VMs
But the common practice is use docker or kubernetes
as it allows easier orchestration
I feel more comfortable with systemd however, is that useable
I'm not sure if you're planning to use AWS but Aurora DB is an interesting concept
It allows different engines - e.g. Postgres, MySQL
and provides scallability around that
Cool, however I feel like starting with a microservice project is like hitting the ground running, and also traveling 30 miles and hour while doing so. My question is, is your GoldenEye bootstrap monolithic? Because I might actually use that so I don't shoot my foot aiming for the ground
Yes, it's more monolithic
or more per module
it focuses on the module experience
Angular can happily live on top of this in the same process, correct?