命名规范

    命名规范也是单一责任原则的一种表现形式，命名规范不只简单的约定命名模版，还要有清晰的层次与类的职责，在良好的层次规范下再约定统一的命名规范。

    命名规范至少需要从模块命名、包命名、类命名、变量、函数命名五个维度去约束。不能只是对函数名称的规范要求。

混乱的原因

命名规范的干扰因素：

1. 内部业务功能的命名

2. 外部功能业务的命名

   比如说我们在给一个类起名字的时候，容易收到内部或外部的干扰，导致了混乱的命名。例如以商品下单为例。

controller的接口，可能命名为OrderController

service 的接口，可能命名为OrderService

   其实OrderController或是OrderService都不是特别的合适，原因在于Controller的命名可能与界面的交互接口所匹配，所以导致OrderController 可能还有订单界面的很多其他的功能，例如查询账户的余额接口、展示商家详情等接口。

    再就是OrderService了，OrderService感觉应该是对Order业务的操作，但是单从下单角度来说，他所涉及到的业务就不仅仅是Order的业务，还会有商品的库存业务、物流的业务、用户的业务、统计的业务，也就是说本身OrderService也是一个混合的业务类。

   但是如果你这样命名了，尤其是OrderService给人感觉应该是所有订单业务都有它负责，但是由于业务的交叉存在，导致OrderService成了一个复杂且混乱的对象，从而失去了它的复用性和可维护性。

解决方案

我们通过一个场景来了解，层次划分的方案

服务台

    服务台的职责是引导，其实就是我们接口Controller层，它是以客户（请求）为导向的，例如你来办理注册公司的业务，那么服务台会告诉你，你应该先办理公司核名、然后在办理材料审核、然后在开户、税务登记、打印执照等流程。

     从软件设计来看，这里可以提出两个层来

     一个是面向UI的Controller层，他的命名可以完成以UI的模块来命名。

      另一个是面向Controller的服务层，他的职责是告诉你窗口的办理流程与每一个窗口所需要的材料等要求，简单来说它就实现了窗口调用层的流程编排。

窗口

     窗口是完整站在业务角度来设计的服务能力，它不关注用户个性化的需求，他只处理本窗口所需要的数据与相关的业务。

     窗口其实也是有自己的service层，他的service层就是具体的业务模型的servce层。与我们三层所说的service层是比一样的。

业务办理

     业务办理其实就是模型交互了，通过模型之间的交互完成业务的办理过程。

档案存档

     档案存档就是对办理过程以及办理结果产生的数据进行保存的过程。

系统架构图

模块层次图

总结

    命名规范的前提要有清晰的层次划分依据，有了划分依旧才能有模版、包、类的划分标准。

然后我们从单一责任原则来命名变量以及函数的命名规范。

小技巧

    为了让团队对模块和专业术语在代码层面表达一致，可以设计一张统一的术语统一表。

表的核心字段有

名称、解释、变量命名、备注