Modular monoliths, DDD and the structure of my packages

At the beginning I wanted to write about modular monoliths vs microservices as I think microservices are overhyped, in many cases they are not necessary unless you are Google or Netflix, but they bring increased complexity to the game:

• you need to take into account that parts of your application may be down,
• debugging is harder as now it's not just one app involved in flow of your logic,
• deployment is also more complicated

But this is not what I want to write about (you can read more on this topic here, and here) . What is more important is how you structure your code. You see, with proper structure you end up with "modular monolith" and with it you can "microservicize" your application without much effort.

When I design an application, I tend to stick to those rules:

• application consists of modules
• each module has its own responsibility (bounded context from DDD), I think of a module as a part of my code which later could be easily extracted into microservice - not part of module, always all of it.
• module provides an api which is used by other modules (and outside world: controllers, jobs etc) to interact with functionality of this module 

I tend to divide module into three java packages :

*.moduleName.published
This is a place where I put all public (or published as public is a java keyword and cannot be used as a package name) code available for use from other modules. This name also implies that classes / interfaces here are published to the world and changing them means changing other parts of the system as well.

*.moduleName.infrastructure
Here go implementations of module adapters (Hexagonal Architecture).  Module's domain does not care what DB or other infrastructure technology is being used, domain defines ports as interfaces whereas infrastructure package implements those ports.

*.moduleName.domain

This is where I put my domain logic: models, application services, domain services, policies etc.