从设计模块化企业应用程序的每个人,我有兴趣知道你如何看待模块化以及你究竟是什么参数？

>基于层的模块化(如控制器/ Web模块,服务模块,域模块)是更好的方法吗？
>或基于特征的模块化更好？为什么？
>在基于特征的模块化的情况下,如何防止/解决依赖于彼此服务的各种功能模块之间的循环依赖性？

它更多的是基于经验的设计问题,因此涉及基于该经验的混合意见.

解决方法:

您应该基于特征,因为基于图层的模块化带来的好处很少.当然,这并不意味着你应该完全忽略(软件)层.

如果您将模块视为可部署组件(例如Maven工件,JARs-within-EAR),其中一个主要动机是将应用程序分解为可以为某些客户/部署打开和关闭的部分.在这种情况下,基于特征的模块化是显而易见的方法.

即使您确定不需要这种部署,我仍然建议使用基于特征的模块化.功能模块之间的接口往往比层之间的接口小得多(因此更易于管理).此外,在两个相邻层上工作的人通常是相同的,因此强制执行模块分离很困难,并且通常只会妨碍隔离带来的任何好处.

除非你在考虑“大层”(UI,业务逻辑,数据库),否则它是可行的.对于这种情况,我建议“矩阵模块化”(即特征和层模块化),但是基于特征的团队/个人责任以及硬件的一些专业角色.例如,一个GUI设计师和几个程序员各自使用包括GUI在内的独立功能模块.

至于问题3：尝试更多地分解这两个模块.它们通常太粗糙了.如果结果不是经过一些思考/讨论,那么你应该人为地将它们分开以避免循环.如果那感觉不对,尤其是如果您以非常小的模块结束,请将它们合并为一个模块.只是不要尝试合并作为第一步.