Uncle Bob once wrote about Screaming Architectures that should aim to at first tell the engineer what the whole enterprise project is about. The idea was that when looking at blueprints of buildings and seeing the structure and the detailed interior you immediately can tell: this is a house, this is a library, this is a train station. The same should hold true for software systems. You should be able to look at the project structure and be able to say: this is an accounting system, this is a book store inventory system, this is an order management system. Is this the case for the most projects we have? Or, does looking at the highest level of modules and packages rather tell us: this is a Spring application, this system has a presentation, business and data layer, this system uses a Hazelcast cache?

The technical implementations are certainly important to us developers. But again, the first thing that we focus on is business concerns. Following this approach, these aspects should be reflected in the project and module structure as well.

Most importantly, this means our domain should be reflected in the application structure. Just by looking at the highest hierarchy of package names should give a good idea of what the software is trying to do. We therefore layer after business concerns first, implementation details second.

Blueprint plans for buildings will also first build up a picture what the building is about, how the rooms are separated, and where doors and windows are located. Then, as a secondary priority they may specify used materials, bricks, and types of concrete being used.

As an outlook for microservices consider the following: designing vertical modules enables the team to split up the application into a system of several applications much more easily. Looking at the module dependencies, for example through static code analysis, provides a picture of where the integration points between the systems would be. These integration points would emerge in some form of communication between the applications. In theory, we can then take that single module, plus minimal plumbing, and package it as a separate, self-sufficient application.

A point on names: by using the term modules we, by now, focus on business driven modules that are realized in Java packages and sub-packages, not build project modules. The term modules then serves more as a concept, less as a strict technical realization.