基于 Oinone 作为研发框架的业务模块划分，需遵循高内聚、低耦合原则，结合 Oinone 的模块化架构特点，以下是最佳实践指南：

一、模块化架构：高内聚低耦合的核心

Oinone 的模块化架构是其技术体系的基石，强调 "高内聚、低耦合" 的设计原则。每个模块作为独立单元，封装特定领域的功能逻辑。在业务模块划分中，应充分利用这一特性，将不同的业务功能封装在独立的模块中，每个模块专注于解决特定的业务领域问题。

（一）功能独立性

每个模块应具备独立的业务功能，避免功能交叉和冗余。例如，将销售管理、采购管理、库存管理等划分为不同的模块，每个模块内部包含完整的业务逻辑、数据模型和用户界面。通过 Oinone 的模块定义文件，可以清晰地声明模块的依赖关系和功能特性，确保模块的独立性和可维护性。

（二）接口设计

模块之间通过定义良好的接口进行交互，而非直接依赖内部实现。Oinone 符合Java面向对象和面向接口编程规范，如模型继承、方法重写、RPC 调用等。在模块划分时，应设计公共的 API 接口，方便其他模块调用和扩展。例如，一个通用的 "客户管理" 模块可以提供客户信息的创建、查询、更新等接口，供销售、服务等模块调用，避免重复开发。一个简化的模块目录结构如下：

Module
├── module-api  模块接口工程
│   ├── model   模型
│   ├── api     服务接口
│   └── Module.java 模块定义
└── module-core 模块实现工程
    ├── action  行为
    ├── service 服务实现
    └── init    数据初始化

（三）依赖管理

合理管理模块之间的依赖关系，避免循环依赖和过度依赖。Oinone 的模块加载机制会自动处理依赖关系，但在设计模块时，应尽量减少不必要的依赖，确保模块的可插拔性。例如，一个报表生成模块可以依赖基础数据模块，但不应依赖特定的业务流程模块，以提高模块的通用性和复用性。

（四）运用事件机制与钩子，实现模块间松耦合通信

Oinone 的事件机制和Hook函数为模块间的通信提供了松耦合的解决方案。在业务模块划分时，通过设计合理的事件触发点，实现模块间的功能扩展和协同工作。例如，在订单处理模块中，当订单状态发生变化时，触发相应的事件，如 “订单已支付” 事件。财务模块可订阅该事件，自动生成财务凭证；物流模块也可订阅该事件，安排商品发货。

（五）模块化成熟度评估体系

评估维度	Level 1	Level 3	Level 5
模块独立性	存在循环依赖	单向依赖	完全独立可部署
变更影响范围	波及多个模块	控制在子模块内	完全模块内闭环
测试效率	需要全量回归	模块级测试	独立自动化验证
认知负荷	需要全局理解	模块接口级理解	聚焦单一模块即可

（六）典型错误模式及解决方案

反模式1：事务驱动型划分 ✖ 将数据库事务范围作为模块边界 ✓ 采用领域事件最终一致性，保持业务完整性

反模式2：技术维度切割 ✖ 按Controller/Service/DAO分层作为模块 ✓ 建立垂直业务模块，每个模块包含完整分层结构

反模式3：过度解耦陷阱 ✖ 将每个类都作为独立模块 ✓ 遵循"共同闭包原则"，将同时变化的类放在同一模块

三、理解 “链接” 模块

参考：与此主题相关的文档可在 “Link 模块” 中找到。

每当我们与其他模块进行交互时，都需要牢记 Oinone 的模块化特性。假设，你同时做了费用管理模块和会计模块。如果我们打算将应用程序出售给企业客户，有些客户可能会需要将费用数据传递给会计系统进行财务处理，生成相应的会计凭证。而有些则可能不需要。 对于这类使用场景，常见的做法是创建一个 “链接” 模块。在我们的例子中，这个模块将依赖于 expenses（费用管理）模块和 account（会计）模块，并包含费用管理中针对报销单创建会计凭证逻辑。通过这种方式，费用管理模块和会计模块可以独立安装。当两个模块都安装后，再安装链接模块就会提供新的功能。

四、渐进式扩展能力

• 继承机制允许通过inherit扩展现有模块，而非直接修改源码。
• 扩展点机制允许通过 Extpoint 追加前置、后置，以及覆盖，来扩展特定函数逻辑。
• Hook机制允许通过 HookBefore 、HookAfter以切面的方式为系统增加通用逻辑。
• Upstream机制允许组合一个或多个模块的入口，并将扩展逻辑在一个模块中进行统一管理。

渐进式扩展的典型场景

阶段	扩展需求	实现方式
初期	基础销售流程	启用原生sale 模块
中期	增加合同管理	安装第三方sale_contract 模块
后期	定制报价审批	开发custom_approval 模块继承sale