服务化

编程思想

OCP原则是什么，你对OPC是如何理解的

1. OCP原则是什么

开闭原则；对扩展开放，对修改关闭。

当我们接入新的业务需求，或者已经业务有新的玩法时，我们应该尽可能少地用修改系统架构、修改领域模型、修改功能模块来应对这些业务变化。而是应该通过增加新的功能模块 领域模型来完成。 这其实就要求 我们设计的架构 领域模型 功能模块 类接口等全部是可扩展的。

2. 对OCP的理解

抽象与分层

尽可能多的识别 可变与不可变、核心能力与扩展点。对扩展开放和对修改关闭，其实就需要我们在系统设计时就尽可能多地考虑清楚哪些是可变的；哪些是核心能力未来可以复用到其他业务场景，可以作为我们的软件资产。

纵向看业务。对业务实际场景讨论分析。抽象不是凭空想象，而是需要针对业务场景进行讨论，在清楚地理解每个业务玩法的基础上，找出这些业务玩法的共性，然后从而设计出通用的模块，通用的领域模型。

横向看功能。模块间共有能力做二次沉淀。 比如对应计费中的调度能力、数据能力、计算能力等，这些能力其实不光是采销计费链路需要，营销计费链路、履约计费链路其实都是需要这种能力的。这需要我们在这些功能模块设计时尽可能做好功能上的抽象，尽可能把业务个性拿到表达式层或者适配层去做。

把可变性和核心能力分层；分表达层与能力层分开。 表达层永远是易变的，不用的业务场景可能有不同的表达方式，最简单的经销待结算流水页面和实销实结待结算流水页面就不可能是完全相同的，毕竟二者计费基础就不完全一样。但是映射到后端数据模型和数据处理能力上，我们不可能完全搞出两套。所以我们对与表达层 领域服务层 基础能力层 基础设施层等 我们要做好分层。只有层次清晰明了了，我们才能把可变层与能力层分开。

组件化和流程编排

服务原子化。新业务新玩法的接入不应该是修改原来代码逻辑，而是新能力的建立和原有能力的编排重新复用。我们可以利用NBF 星环等实现业务流程可视化 业务流程可编排。

可扩展和可配置

当我们把可变性分析和分层出来之后，我们就需要考虑如何应对这些可变性，如何做到对扩展开放和对修改关闭。

从架构上 我们应该做到低耦合、单一原则。以SCM3.0为例，SCM的单据池、受理和计费结果是完全耦合在一起的，链路强耦合且模型强耦合。比如单据池新接入一种单据，往往是计费需要做迭代、结算需要做迭代。并且由于链路强耦合，如果计费处理失败了，则整个单据都将丢失，甚至无法重试。

从实现上，我们应该识别出来业务逻辑中哪些是变化的逻辑，哪些是不变的逻辑。对于可变的逻辑。我们可以通过策略模式，借助于TMF、NBF这些框架，做到的可变点的可扩展。还有一些扩展点，其实是可以做成配置化的。比如计费公式，每个业务每种单据都有可能是不一样的；这种，我们可以在利用规则引擎，把计费公式做成配置，代码里沉淀下脚本执行能力。

类的开放有哪几种技术方式，一个产品的开放方式可以用哪几种技术方式

类的开放有哪几种技术方式

1. 单一原则 原子服务：越原子的服务 复用性就越高。
2. 抽象约束，面向接口和抽象编程：对类做好抽象，提供保持接口的稳定，不同的子类和实现类完成不同的业务处理流程。不同的实现类之前可以相互替换
3. 多态：多态也是保证类可扩展，可复用的一种手段。
4. 策略模式：利用动态策略模式 把类中可变逻辑识别出来，做成可扩展。

产品的开放方式

1. 产品能力的原子化：原子化的产品 才是最可能被复用的能力。
2. 服务可视化、业务流程可视化、业务流程可编排。
3. 扩展性可配置。

举个符合ocp原则的类，说明为什么符合

新计费平台中的com.alibaba.ascp.finance.charge.container.service.component.charge.BillChargeExecutorTemplate

这个类首先分析了各种计费场景的可变与不可变点，利用策略模式+模板设计模式做到公用能力复用，可变点的扩展性。另外，通过计费转换脚本、公式配置化。形成一套标准模板能力。未来新的计费逻辑接入，只需要配置转换脚本和计费公式。

举个不符合ocp原则的类，说明为什么不符合

SCM3.0中的com.alibaba.ascm.biz.settlement.api.service.impl.SettleMessageServiceImpl统一消息处理类。

这是个大而全的类，SCM中采购类消息、交易类消息，甚至其他规则同步类消息等都放到这个类中。由于太大而全了，导致各种场景处理逻辑搅乱在一起。后面的同学改起来，只能小心翼翼，识别出自己的逻辑，然后配上万能的if else。