A Tour of MallBot
Learn about the responsibilities and infrastructure of the monolith modular.
We'll cover the following
Our MallBots application is a modular monolith, which is an application design that sits somewhere between a classic monolith design and a microservices application design. We have most of the benefits of both designs with only a few downsides.
The responsibilities of the monolith
The root directory of our code is kept minimal, and what stands out are the module names. We intentionally avoid the use of generic or general layer names, such as controllers, config, or models, in the root directory. We use application component names, such as baskets, stores, depot, and ordering instead so that we end up with a code repository that looks like an application that deals with shopping and not like some generic, no-idea-what-it-does application. Each of these modules is a different bounded context in our application.
Screaming architecture: The organization we’re using for our root-level directory structure is called screaming architecture, which is credited to Robert C. Martin.
It isn’t just modules that we will find in our root. We do have some other directories that are necessary:
/cmd: This is a typical root-level directory for Go applications. This directory will contain one or more child directories for each eventual application we can generate from the code./internal: This is a special directory for Go code bases that receives special treatment from the compiler. Anything in this directory or its child directories is only accessible to the parent directories or sibling directories of the internal directory. Seeing an internal directory is a signal to other developers that the code within is not meant to be imported into any outside applications, and this intention is backed up by the compiler./docsand/docker: Additional utility directories containing documentation and scripts to aid in the understanding and local development of the application.
Shared infrastructure
The monolith creates or connects to all parts of the infrastructure that it and the modules will be using. References to the infrastructure are then passed into each module to be used in whichever way that module needs to use the connections. The modules will not create any connections to the infrastructure themselves:
Get hands-on with 1400+ tech skills courses.