Over the years, the first step in designing a Java application has usually involved the design of the packages and classes, as well as the interactions between them. It also perhaps involved designing some shared libraries. For instance, you'd move reusable code into a separate project and bundle it into your application as a JAR file. With Java 9 modules, you now have a new aspect to consider that significantly impacts the design process. Irrespective of whether you are creating a new application from scratch or you are migrating an existing classpath application into a modular application, there are some common questions you'll need to answer--How do you come up with a modular design? How do you choose what a module should be? How much code and functionality should be in a module? Where do you draw module boundaries in specific scenarios? For example, a question you might often run into is--Given a functionality or a set of classes and packages, should they belong to Module A or Module B? And how do you achieve good design principles for modules such as reusability, extensibility and maintainability?

As with most software design challenges, there are no right answers that apply for all scenarios. In fact, some of the -ility factors pull against each other, and most designs involve making a calculated trade-off. However, having some guidelines and best practices should get us started with tackling these challenges that can then be refined and tweaked as per specific use cases.

Among the first steps in designing and building a modular application, it helps to have a high level idea of what the modules and APIs will be. For simple projects, it can be tempting to just fire off the IDE and start coding. But for anything serious, it helps to spend some time and design a rough picture of the modules involved, their public APIs and their dependencies on each other before you start coding. Let's start looking at some principles and factors to keep in mind when designing modules and deciding what it should do.