你的单体可以模块化到什么程度？第七部分 - 真正的模块化单体并不存在？
内容提要
本文讨论了“模块化单体”概念，指出实际上并不存在真正的模块化单体，建议使用“领域导向组件架构”术语。单体架构可通过合理的层次和模块设计改善，关键在于将架构与应用的子域和团队对齐，以提高开发效率。
延伸解读
术语之争：为何“模块化单体”不准确
文章指出，单体架构是将应用作为单个组件（如WAR或JAR）的架构风格，从应用架构视角看，组件是黑盒。因此，“模块化单体”实际描述的是组件的内部架构，而非单体架构本身的特性。作者类比“微服务”是“微服务架构”的简称，认为“模块化单体”同样存在术语混淆，建议使用“模块化组件”或更准确的“领域导向组件架构”。
模块化并非单体独有
文章强调，模块化的重要性并非单体架构所独有。微服务架构中的服务同样可能由多个子域/限界上下文组成，且可能由不同团队拥有，因此也需要模块化。这意味着“模块化单体”模式解决的问题并不局限于单体架构，将其视为单体专属可能误导架构决策。
真正的问题：架构与子域、团队的对齐
文章认为，单体应用不一定是“大泥球”，它可以有清晰的层次和模块。真正的问题在于层次和模块往往按技术划分（如web、domain、persistence），导致一个子域/限界上下文横跨多个层和模块，且与团队结构不匹配。这反映了传统筒仓式组织，而非现代Team Topologies组织。
领域导向组件架构：以子域为顶层组织原则
文章提出，模块化单体（组件）模式的核心是以领域/限界上下文作为顶层组织原则。例如，单体由customers、orders等模块组成，每个模块内部再分层。这样，应用架构与团队对齐，减少跨层跨模块的变更。作者认为“领域导向组件”或“领域导向组件架构”比“模块化单体”更准确。
Q&A
什么是模块化单体？
模块化单体是将应用程序结构化为单个组件的架构风格，但实际上并不存在真正的模块化单体。
为什么建议使用‘领域导向组件架构’这个术语？
因为‘模块化单体’实际上描述的是组件的内部架构，而不是单体架构的特性，‘领域导向组件架构’更为准确。
单体应用程序如何避免成为‘泥球’？
单体应用程序可以通过合理的层次和模块设计改善结构，避免成为‘泥球’。
单体架构的关键设计要素是什么？
关键在于将架构与应用的子域和团队对齐，以提高开发效率。
模块化单体的概念与微服务架构有什么区别？
模块化单体描述的是单一组件的内部架构，而微服务架构则是将应用结构化为多个松耦合的服务。
如何确保单体架构与团队的对齐？
通过将层次和模块与团队负责的子域/边界上下文对齐，确保架构与团队的对齐。
