I love a good monolith. It’s easy to develop and maintain, deploy and scale. It’s a real beauty. But, as with everything, developing in a monolith has its trade-offs and requires some effort to keep it from being a huge bottleneck to our companies and teams.

If there’s no care about keeping a separation by business domains (yep, DDD) it ends up creating a lot of attrition, coupling, and conflicts between the teams. With well-defined domains, changes in a domain have a very low possibility of impacting other domains.

The ease of deployment carries a huge responsibility. Since the monolith is deployed as a whole, there’s little to no way to really only do it when all teams have finished their work completely. Unfinished features must be protected from executing or we risk having errors thrown at the user and the application terminating unexpectedly. Feature flags allow the continuous deployment of the monolith, deferring access to unfinished features for a posterior occasion.

The development itself gets limited to one or two programming languages. In the context of web applications, for example, this can mean having a backend and a frontend language (in the case of a full-stack app). This can impact how recruitment is done in the company and the talent pool available.