More down to earth, how do we find reasonably sized and structured modules?

Putting business concerns first, a good start is to draw overviews of all the responsibilities and use cases of the application. This may be part of a brainstorming session, ideally together with business domain experts if that step hasn't been done before. What are the application's responsibilities? What business motivated use cases do we have? Which coherent functionality can be seen? The answers to these questions already give a good idea which modules are likely to be represented, without focusing on external systems, implementation details, or framework choices.

In this step we also already consider dependencies between these business concerns. Dependencies are helpful indicators of whether modules should be split up or, especially when circular dependencies are found, should be merged together. Constructing these overview diagrams, starting from a higher level and working the way down in several iterations will give a clearer image of what the business contents of the application are. Generally speaking, the identified modules should match well with the business aspects identified by the domain experts.

To give an example, an online shopping application could identify modules for users, recommendation, articles, payment, and shipping. These would be reflected as the base domain modules:

The identified modules represent the base Java packages in our application.

It makes sense to put some effort into these considerations. However, as always, any definitive structure or implementation, no matter whether on code or module level, should be able to be changed later on. New requirements might emerge or there might be a better understanding later on, once the developers start to deep dive into the domain. Iterative refactoring, no matter on which level, will improve the quality of the system.

Chapter 8, Microservices and System Architecture, will show similar motivations and methodologies when designing systems that comprise distributed applications. Particularly, the Domain-Driven Design approaches of bounded contexts and context maps will be discussed.