主要观点总结
本文介绍了作者独立项目中使用的模块划分方式和相关技术思路，包括十几个模块的主要职责和相互关系。文章强调了理解业务的重要性，以及在项目中使用框架的必要性。同时，文章介绍了作者项目中具体的模块划分方式，包括Framework、Biz Framework、Common Biz、Features、Plugins和Application等模块的作用和设计原则。
关键观点总结
关键观点1: 模块拆分与业务和技术架构的关系
作者介绍了项目中模块拆分的主要目的，是为了降低未来修改成本，并反映技术架构和业务架构。同层级的模块互相独立，依赖关系单向。强调理解业务的重要性，以及在业务形式化建模后的软件架构设计。
关键观点2: Biz Framework和Framework的作用
Biz Framework是业务上的框架，包含项目基石业务的抽象和基础接口；Framework是技术上的框架，包含纯技术、业务无关但根据业务需求编写的通用能力。
关键观点3: Common Biz和Features模块的职责
Common Biz负责通用业务模块，如数据分析、通用UI组件等；Features模块包含独立的业务，不同Feature之间可能会有互相跳转的需求，可通过Visitor接口或路由实现。
关键观点4: Plugins模块的插件化架构作用
Plugins模块作为插件化架构的插件层存在，用于实现一些可能的动态功能或依赖于运行环境的功能。插件层一般不被其他模块依赖，可以通过依赖注入或SPI机制获取其实现。
关键观点5: Application模块的简单介绍
Application模块主要用来组合所有的Feature模块，一般不会包含太多代码。对于跨平台项目，可能存在多个Application模块，每一个对应一种平台。
文章预览
最近几天忙着搬家，代码几乎没怎么写，趁着周日晚上有点空来水一篇文章。 大概两年前决定自己做个独立的项目作为未来几年的空余时间消磨利器，并且在其中尝试使用各种最新技术，然后业务也比较复杂（不然也不能做这么久），现在项目迭代了这么久，也上架一段时间了，打算写点文章大概介绍下里面用到的一些技术和思路。 现在项目中大概有十几个模块， 拆分模块的主要目的是为了降低未来的修改成本，同时模块的拆分也能反映出技术架构和业务架构 。 目前项目的模块关系图大概如下图所示。 上图中的所有同层级的模块都是平行模块，这意味着它们不会互相依赖，模块的依赖关系按照图中箭头的方向单向依赖。 1 理解业务 不同的软件有不同的业务，模块设计应该因地制宜，一个好的设计一定是需要先充分理解业务的。 如果两个模块
………………………………
