2、系统应用定制基础：理解系统架构、模块划分与定制化需求
做系统定制，第一步不是急着写代码。而是先把系统的骨架看清楚。
我习惯把系统架构拆成三个核心层次来看：表现层、业务逻辑层和数据访问层。为什么要分层？说白了就是让各部分各司其职，互不干扰。你改你的界面，我改我的逻辑，他改他的数据，彼此不打架。
2.1 系统架构的核心层次
先聊聊表现层。这一层直接跟用户打交道，页面、表单、按钮、图表都在这里。定制需求往往最先落在这层——换个Logo、改个配色、调整一下布局。
业务逻辑层是系统的大脑。所有的规则判断、流程编排、计算处理都在这里完成。定制化里最复杂的部分，基本都集中在这一层。比如审批流程怎么走、价格怎么算、权限怎么控。
数据访问层负责跟数据库打交道。增删改查、事务管理、缓存策略，归它管。定制需求里涉及数据源切换、字段扩展、历史数据迁移，都得动这一层。
我的经验：我记得刚入行那会儿，参与过一个ERP系统的定制项目。代码全揉在一个包里，改个按钮颜色都要翻半天。后来架构分层重构之后，效率提升了不少。分层越清晰，定制越省心。
2.2 模块划分的原则
模块划分这事，说起来简单做起来难。我在项目中遇到过模块划分不清导致返工的情况，所以深有体会。
核心原则就两个：高内聚、低耦合。
- 高内聚——一个模块内部的功能要紧密相关。用户管理模块只干用户的事，别掺和订单的逻辑。
- 低耦合——模块之间的依赖要尽量少。改了一个模块，别让其他模块跟着遭殃。
怎么划分模块？我一般按功能域来切。用户管理、订单管理、库存管理、支付管理，各自独立成模块。模块之间通过接口通信，接口定义得清晰，后续定制就轻松。
举个例子：
// 接口定义要足够稳定
public interface OrderService {
Order createOrder(OrderRequest request);
Order cancelOrder(String orderId);
List<Order> queryOrders(OrderQuery query);
}
// 不同客户可以有不同的实现
public class CustomOrderServiceA implements OrderService {
// 客户A的定制逻辑
}
public class CustomOrderServiceB implements OrderService {
// 客户B的定制逻辑
}避坑：我曾经参与过一个项目，模块间的接口定义得过于宽泛，参数里塞了一个巨大的Map。结果定制时谁都不敢动那个接口，怕影响其他模块。接口设计一定要收敛，参数明确，返回值明确。
2.3 定制化需求的分类与管理
定制化需求看着五花八门，但归纳起来无非三类：
| 类型 | 实现方式 | 适用场景 | 维护成本 |
|---|---|---|---|
| 配置化定制 | 配置文件、环境变量、数据库参数 | 开关切换、参数调整、简单行为变更 | 低 |
| 插件化定制 | SPI接口、钩子函数、扩展点 | 功能增强、第三方集成、流程扩展 | 中 |
| 代码生成定制 | 模板引擎、代码生成器、脚手架 | 大量重复性定制、新模块创建 | 高 |
我建议，能用配置解决的绝不用插件，能用插件解决的绝不生成代码。为什么？因为配置化的维护成本最低，升级时基本不受影响。
你想想看，如果每个客户都生成一套独立代码，那后续版本升级就是噩梦。我见过一个项目，因为过度使用代码生成，导致同时维护了十几个分支，每次合并都痛不欲生。
我的教训：我曾经犯过一个错误，把客户的业务逻辑直接写死在代码里，用if-else硬编码。后来客户说"我要改一下规则"，我改了一个通宵。从那以后，凡是可能变化的地方，我都先问一句："能不能做成配置？"
2.4 架构与定制的关联
架构设计直接影响定制化的难易程度。好的架构让定制变得简单，差的架构让定制寸步难行。
举个例子：如果业务逻辑层和数据访问层耦合在一起，那要更换数据库就非常困难。反之，如果层与层之间通过接口隔离，更换数据库只需要开发一个新的数据访问实现即可。
定制化对架构的要求，可以总结为几点：
- 可替换性——每一层都可以被替换或扩展，不影响其他层
- 可配置性——关键行为通过配置来控制，不需要改代码
- 可观察性——定制后的行为可以被监控和追踪，出了问题能快速定位
核心观点：做系统定制之前，先搞清楚系统的架构，再分析模块划分，最后评估定制化需求。这个顺序不能乱。架构是骨架，模块是器官，定制化需求是血液——骨架不正，器官难安，血液不畅。
回到最开始的问题：为什么要先理解架构和模块划分？因为定制化不是打补丁，而是在系统骨架上做加减法。骨架不正，后面全是坑。把架构吃透了，模块分清了，定制化需求来了才不会手忙脚乱。