General Modular design for a web application [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. Closed 10 years ago.

From everyone who've designed a modular enterprise application, I am interested in knowing how do you perceive modular开发者_开发百科ization and what exactly are you parameters?

1. Is layer-based modularization (like controller/web module, service module, domain module) a better approach?
2. Or feature-based modularization better? And Why?
3. In case of feature-based modularization how do you prevent/solve circular dependencies between various feature-modules dependent on each other's service?

It's more of a design question based on experience and thus involves a mix of opinion based on that experience.

---

You should go feature-based as layer-based modularization brings very little benefits. Of course this doesn't mean that you should completely ignore (software) layers.

If you think about modules as deployable components (say Maven artifacts, JARs-within-EAR), one of the main motives for this is to break up the application into parts one can turn on and off for certain customers / deployments. In this case feature-based modularization is the obvious way to go.

Even if you're sure you won't need that kind of deployment, I'd still suggest going with feature-based modularization. Interfaces between feature modules tend to be much smaller (and thus easier to manage) than between layers. Also, people working on the two adjacent layers are usually the same, so enforcing module separation is hard and often just gets in the way without any benefits the isolation brings.

Unless you're thinking about the "big layers" (UI, business logic, database), in which case it's doable. For this case, I'd suggest "matrix modularization" (i.e. both feature and layer modularization), but with feature-based teams / individual responsibilities with a few specialist roles for the hard parts. For instance, one designer for GUI and several programmers each working separate feature modules, which include GUI.

As for question 3: try breaking down those two modules even more. They're usually too coarse. If they turn out not to be after some thinking / discussion, you should artificially split them just to avoid the circularity. If that feels wrong, esp. if you end with really tiny modules, merge them together into one module. Just don't try merging as the first step.