标签：java oop modularity

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

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

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

解决方法:

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

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

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

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

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

标签：java,oop,modularity
来源： https://codeday.me/bug/20190630/1341372.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。