高内聚、低耦合是六大设计原则自然作用的结果；需以单一职责划定模块边界，依赖倒置与接口隔离控制调用关系，开闭原则支撑扩展性，迪米特法则约束对象可见性。
高内聚、低耦合不是目标，而是设计原则自然作用后的结果。真正要做的，是把六大核心原则（单一职责、开闭、里氏替换、接口隔离、依赖倒置、迪米特法则）作为日常建模的“检查清单”，而不是抽象概念。
用单一职责原则划定模块边界
一个类只负责一个明确的业务能力，比如 OrderService 只处理订单生命周期逻辑，不掺杂支付校验或库存扣减；支付校验交给 PaymentValidator，库存操作由 InventoryService 承担。这样每个类内部逻辑紧密（高内聚），类之间仅通过清晰契约通信（低耦合）。实际中可问自己：如果这个功能变了，是否只改这一个类？如果不是，说明职责已溢出。
靠依赖倒置+接口隔离控制调用关系
高层模块（如订单创建流程）不依赖具体实现（如微信支付、支付宝），而是依赖抽象接口（PaymentProcessor）。同时，这个接口只定义“发起支付”和“查询状态”两个方法，不塞进“退款”“对账”等无关行为——这就是接口隔离。好处是：更换支付渠道只需新增实现类，不碰原有代码；不同场景（如前台下单 vs 后台补单）也能按需组合小接口，避免大而全的臃肿契约。
以开闭原则支撑可扩展性
当系统需要支持新业务类型（比如新增“跨境订单”），不应修改已有 OrderService 的 if-else 或 switch 分支，而是定义 OrderHandler 接口，让每种订单类型各自实现自己的处理器，并通过工厂或策略注册进来。原有主流程不变，只增加新类——对扩展开放，对修改关闭。这种结构天然减少模块间硬依赖，也便于单元测试和独立演进。
用迪米特法则约束对象间的可见性
一个类只与它的“朋友”通信：参数、自身创建的对象、聚合/组合的成员。例如，Order 类持有 Address 对象，但不应直接调用 address.getProvince().getCode()；而应让 Address 提供 getProvinceCode() 方法封装细节。这样 Order 不了解 Province 的内部结构，未来地址模型调整时，影响范围被锁死在 Address 内部。
