Web 应用程序的通用模块化设计
对于每个设计过模块化企业应用程序的人来说，我很想知道您如何看待模块化以及您的参数到底是什么？
- 基于层的模块化（如控制器/Web 模块、服务模块、域模块）是更好的方法吗？
- 还是基于功能的模块化更好？为什么？
- 在基于功能的模块化的情况下，如何防止/解决依赖于彼此服务的各个功能模块之间的循环依赖关系？
它更多的是一个基于经验的设计问题，因此涉及基于该经验的各种意见。
From everyone who've designed a modular enterprise application, I am interested in knowing how do you perceive modularization and what exactly are you parameters?
- Is layer-based modularization (like controller/web module, service module, domain module) a better approach?
- Or feature-based modularization better? And Why?
- 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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您应该基于功能，因为基于层的模块化带来的好处很少。当然，这并不意味着您应该完全忽略（软件）层。
如果您将模块视为可部署组件（例如 Maven 工件、EAR 内的 JAR），那么这样做的主要动机之一是将应用程序分解为可以为某些客户/部署打开和关闭的部分。在这种情况下，基于功能的模块化是显而易见的选择。
即使您确定不需要这种部署，我仍然建议采用基于功能的模块化。功能模块之间的接口往往比层之间的接口小得多（因此更易于管理）。此外，在两个相邻层上工作的人员通常是相同的，因此强制执行模块分离很困难，而且通常只会造成阻碍，而隔离带来的任何好处都没有。
除非您正在考虑“大层”（UI、业务逻辑、数据库），在这种情况下它是可行的。对于这种情况，我建议“矩阵模块化”（即功能和层模块化），但具有基于功能的团队/个人职责，并为困难部分配备一些专家角色。例如，一名 GUI 设计师和几名程序员各自工作独立的功能模块，其中包括 GUI。
至于问题 3：尝试进一步分解这两个模块。它们通常太粗糙。如果经过一些思考/讨论后结果证明它们不是，你应该人为地分割它们以避免循环。如果感觉不对，尤其是。如果你最终得到的模块非常小，请将它们合并到一个模块中。只是不要尝试将合并作为第一步。
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.