企业级封装需系统性落地，核心是控制访问权与明确责任边界；按层级划分：领域模型层校验赋值、服务层用不可变DTO、网关层封装调用细节、SDK层隐藏实现并统一封装异常。
封装在企业级开发中不是写几个 private 字段加 getter/setter 就算完成，而是要结合系统边界、团队协作和长期演进来系统性落地。核心在于“控制访问权”和“明确责任边界”，而不是单纯隐藏字段。
按层级划分封装粒度
企业项目通常存在多层结构，不同层级的封装重点不同：
- 领域模型层：属性私有化 + 带校验逻辑的 setter（如年龄限制在 0–150，邮箱格式校验），禁止无约束赋值；构造函数设为 private 或受控（如使用 Builder 模式）
- 服务接口层：对外暴露的 DTO 类必须是不可变的（final 字段 + 无 setter），用 builder 构造；避免直接返回实体类，防止内部结构泄露
- API 网关/客户端层：封装远程调用细节，统一处理 token 刷新、重试、熔断、日志埋点；调用方只关心“我要发消息”，不关心 endpoint、签名算法、超时配置
-
组件/SDK 层：提供清晰的初始化入口（如
WeComClient.init(config)），隐藏认证管理、连接池、序列化等实现；所有异常统一转为业务可识别的错误类型（如AuthFailureException）
用访问修饰符守住关键防线
不能仅依赖 private，要结合包结构与修饰符形成防御纵深：
- 核心算法类、敏感工具类放在独立包（如
com.company.security.crypto），用package-private（默认修饰符）限制同包内使用，避免被业务模块随意引用 - 供子系统扩展的钩子方法用
protected，但必须配 Javadoc 明确说明“仅限继承重写，不得直接调用” - 所有 public 方法必须有明确契约：输入参数范围、空值容忍度、线程安全性、是否幂等——这些不是注释，而是接口设计的一部分
封装要配合可观测与演进机制
企业系统持续迭代，封装若缺乏配套机制，反而会成为技术债源头：
- 每个封装模块需自带版本标识（如
@ApiVersion("v2")），网关层支持路由到不同实现，避免“改一个接口，全量发布” - 关键封装类提供健康检查端点（如
/health/db-connection），暴露内部状态而非让调用方猜问题 - 对已废弃的 public 方法，不直接删除，而是用
@Deprecated(forRemoval = true)标注，并在日志中记录调用栈，留出至少两个大版本过渡期
警惕常见反模式
这些做法看似封装，实则破坏封装本质：
-
Getter/Setter 泛滥：暴露全部字段的 set 方法，等于把 private 改成 public 的假动作；应只开放必要操作，如用
changePassword(old, new)替代setPassword(String) - DTO 与 Entity 强耦合：数据库实体类直接 @Data 注解后返回给前端，导致字段变更牵一发而动全身；必须通过显式转换（MapStruct 或手动 copy）隔离变化
- “封装”成黑盒函数：一个方法里塞入数据库查询、HTTP 调用、文件写入、日志记录，职责混乱；应拆分为小单元，各自封装，再由上层编排
