[Refactoring this question out of a previous post that combined it with a question about pricing / cost.]
The question is: how should one best organise a large system within Kalix?
Currently, it seems the suggested approach is “Project contains Services contains Components (e.g. Entity, Actions, Views).”
For a large system this seems to mean a project could contain quite a large number of services, and misses the abstraction of subsystems, e.g. related to bounded-contexts. In many cases, it would seem to be appropriate to start and stop all services within a subsystem at the same time.
So, should one just use many projects, i.e. one project for each subsystem?
This may be workable, and would all these services to be managed as a group, but does it complicate the communication between the services within different projects / subsystems, e.g. requiring pub/sub or similar, rather than just message-broker-less communication between services.
Or could Kalix benefit from the ability to have projects containing subsystems that that are collections of services that can be managed as a group?
Thanks for any suggestions.
Cheers,
Ashley.