Although a monolith can be modeled in a respectable way, often they are turned into a big ball of mud. This is caused by multiple domain models becoming entagled within the monolith, and in Vaughn Vernon's experience this can happen within a few weeks or months, he claimed in a presentation at the Scala Days conference earlier this year.
Vernon, author of Implementing Domain-Driven Design and Reactive Messaging Patterns with the Actor Model, notes that when domain models which should be kept separate are mixed together, so that they can’t be distinguished from each other, it becomes difficult or impossible to logically reason about the models together with the business and the domain experts, making the application or system worse than a monolith.
An alternative to a monolith is microservices, but how do we define a microservice? How big is it? Sometimes lines of code are proposed for defining the size of a microservice, and Vernon has seen figures in the order of tens of lines up to a thousand lines, but he argues against such a broad and imprecise definition.
Vernon also reacts to enterprises that claim to have microservices in the hundreds but not knowing or caring about the exact number. They argue that it’s not worth the effort finding their actual usage since it’s so cheap to just let them run. Vernon disapproves of this and notes that among other things, infrastructure can have a big impact on how many microservices we can run and still be resilient to failure scenarios.
Vernon recommends a prescriptive approach for deciding the size and count of microservices within a system: using a Domain-driven design (DDD) approach, especially bounded contexts. He notes that within the microservices community sometimes a bounded context is defined to have just a single entity, but he finds that very unlikely. Instead, Vernon favours modelling microservices in a bounded context determined in size by the ubiquitous language, and refers to a book by Sam Newman: Building Microservices.
To get started with microservices, Vernon recommends starting with one service per bounded context. He believes that even if we can find components within a bounded context that might be considered microservices in themselves, their cohesiveness and collaboration means they should be kept together within one service. He also recommends that one service and one bounded context should be one deployable unit. With experience though, they may become more fine granular, creating more microservices and deployable units for a bounded context, maybe for scalability reasons.
Besides entities, the ubiquitous language also includes command and event messages. These messages can be used in an event-driven architecture by publishing the events for eventual use of other microservices. Vernon concludes his presentation showing an example of building microservices using the Actor model, implemented with Akka and Scala.
