I work for a country-wide company, so the software we develop is large scale.
Our core system is Web based including webservices
. We are currently redesigni
The key aspect of modularity is that your module knows as little as is humanly possible so that it can be reused in many different contexts. Bugs only occur when an assumption is violated, minimizing the assumptions is the biggest bug killer. OSGi provides tools like µservices that are very good in allowing assumptions to remain local.
Your layout looks very much like a web project, which imho is wrong since most code we have to develop ourselves should be independent of the technology used to present it. All this technology is likely to change in the near future since web applications are shifting rapidly to the browser, browsers are becoming fat clients again. I.e. the very modern REST interfaces already feel very old fashioned if you see what pure messaging is doing. All this volatility means that you want to make your modules as decoupled as possible.
So I would never couple any domain code to anything that is coupled to libraries that are coupled to web technology. These transitive dependencies are going to hurt you in the (near) future. Built small cohesive uncoupled modules and then use them as lego blocks to build your applications.