I like this way of thinking about services; decoupling the "project model" from the "deployment model" is a good way of thinking about things. Some random thou

I like this way of thinking about services; decoupling the "project model" from the "deployment model" is a good way of thinking about things. Some random thoughts: * What build toolchains are suited to these arbitrary DAG arrangements? Bazel? Perhaps I missed a reference in the article, but I'd be interested in the author's take on this, and of course any thoughts from the community here. * The "testing monolith" is a pattern that I've used in a less well-named fashion, and it's great for cases where lots of code-services need to execute a business process that might span weeks or months; building a test rig to mock time across an ensemble of microservices sounds like an interesting challenge; mocking time inside a single process running the combined logic of all the services is much more palatable. (This isn't really possible if you use multiple languages though, so it only gets you so far). * DDD bounded contexts as service boundary -- this is a good starting point, especially if you take a loose definition of "service". Under the DDD definition of "Service" you can actually have multiple deployables running; for example a typical Django/Rails monolith will have a DB (SQL) and an async worker (Celery/Sidekiq via Redis/RMQ) and perhaps a cache (Redis) so it's really a bunch of different deployables, even if we refer to it as a "monolith". Likewise with smaller services. If you think of the Service as being a constellation of processes with an external API, then you can start splitting out parts into separate deployables without the outside world caring, say to scale a particular workload independently of the rest of the Service logic. This is kind of the direction that Uber ended up moving in with their "Domain Oriented Architecture" (https://eng.uber.com/microservice-architecture/ https://eng.uber.com/microservice-architecture/). This is actually how Django monoliths already work; you use the same codebase to specify your sync API workers, and your async Celery tasks, and you'll deploy them as separate deployables from the same repo.