The question is contextually related to this question and an issue I raised in regards to generating SQL scripts for sagas.
I’m seeking clarification on the correctness of my current strategy for how to structure repositories and deploy their code. FYI I use Kubernetes so deploy all hosts (whether web app, api, or NSB endpoint) as docker containers. I’m also a team of one with possible addition of 2 other devs soon. No code is in production so safe to change everything.
I’ll first explain how my business service’s are structured.
As per Udi’s training videos he describes a logical business service as being something that can be realised as a source code repository, the build artifacts of which should only be NuGet packages representing the service’s autonomous components - the physical model of the service’s use cases. This is how I structure my business services. There can be many AC nuget packages for a single service, built and published to a feed, all at the same version.
The service’s ACs are typically a mixture of 2 types:
- Backend ACs. These only deal with handling messages. The handlers can be regular message handlers and/or sagas. Non-saga handlers can modify a readmodel database.
- ViewModel composition ACs. These handle http requests and either send messages, handle messages for propogating to a signalr hub, or query a readmodel database.
So within the boundary of the service and its repository there are many ACs that are dependent on a shared database schema. Coupling within the boundary but not outside the boundary.
Hoping I haven’t deviated from sanity at this point?
Now let’s consider hosting the ACs when considering the situation where I have more than one service structured and published this way. Two separate repositories; Sales and Finance, each with the 2 types of ACs packaged and deployed to a feed.
In the context of hosting I have a separate repository that has the following apps:
- Admin web app - hosts a combination of viewmodel ACs from both services plus some web component ACs.
- Web API - serves several mobile apps. Hosts a combination of viewmodel ACs from both services. Likely different ACs to those hosted in admin web app.
- Sales worker - hosts only sales service backend ACs.
- Finance worker - hosts only finance service backend ACs.
Each of the apps has a Dockerfile for creating the docker image during a PR merge ready for deployment to whatever environment is required. Each app (host) startup code performs service AC registration using convention for whatever AC package references are included in the app’s project.
Now the question. Is this “hosts” repository correct to have all the apps together or should there be separate repository per host?
I’ll explain why I’ve put them together but really looking for clarification that this deployment setup is appropriate or are there alternatives in a docker environment?
The reasoning behind all these apps existing in the one “hosts” repository is so that it’s possible to deploy a vertical upgrade of a service’s capability, both in terms of behaviour across layers but also at a data schema level too.
For example, let’s say a sales service has 2 ACs, one being viewmodel and the other being backend, but both are dependent on the same data schema. The coupling each has on the schema means they should be upgraded together, and in addition, the schema should also be migrated at the same time. If the viewmodel AC is hosted separately to the backend AC then for system stability both hosts should be deployed together and the database migrated as part of the same deployment.