最近一季度KPI中，增加了一项单元测试覆盖率

在之前工作经历中，也有过类似情况，老板开始关注单元测试情况了，就会加上覆盖率这个绩效指标，不管以前如何应对，还是再次关注了一些对于测试的文章，TDD虽然没有大流行，但这个概念还是常被人提起

这张图是在一篇文章中看到的

好写单测的系统往往比不好写单测的系统更加健壮，如果一个系统大部分代码都可以写无 Mock 单测，那么它看起来就像左图一样，外部调用只是薄薄的一层，可以随意更换。

如果你的系统大部分代码都一定要 Mock 才能测试的话，或者根本无法测试的话，就像右图一样，说明你的业务根本就没有自己的核心逻辑，而是和各种外部调用缠绕在一起

这张图让我有很多的感触，值得整理一下思绪

领域模型

这张图跟整洁架构图特别像

中心是核心的业务逻辑，依赖路径是由外向内，外围千变万化，但内核是不变的

不管是设计，还是编码，亦或是UT，都需要这样的思路；需要高内聚，核心业务代码不能分散，集中，有中心脉络

我们有时过多注重了技术层次，比如MVC，我们更多的是关注各层技术变化速率而分层，而忽略了业务层次变化

结合之前分析的《DDD分层》，也应该是三层，但不是MVC，面是是输入、领域、输出三层，类似端口适配器架构

向心力

这可能跟图的形状有关，因为是圆形。所以想到了向心力这个词，业务逻辑要内聚，单元测试也要内聚，当然了，单元测试的内聚是由于业务逻辑的内聚。

而这种高内聚，正合了向心力。没有向心力就是一群散沙，设计是，架构是，团队亦是

功夫在诗外

以前还写过一篇《功夫在诗外》，为了专业有所精进，就去看了很多专业无关的书，似乎方向搞错了，灵感不是平白无故地出现的，而是长年持续思考累积，再因为偶尔一件诗外之事激发，贯穿了之前的整个思考过程

以前看整洁架构那张图怎么没有如此些感悟呢，因为作为一名程序身在其中，但当看到测试内容时，因不是测试人员，身在事外看事，就有了感悟，所以功夫不能完全花费在诗外，也不能离诗过远，才能带来灵感

最近在团队中引入checkstyle ，自动执行规范检查，加入到ci步骤里面，让流程工具化，工具自动化，摆脱人工检查，在团队开发中硬性统一，更便于协作顺畅

checkstyle里面有个规范：所有local variable必须修饰为final

这是为什么呢？

final是Java中的一个保留关键字，它可以标记在成员变量、方法、类以及本地变量上。一旦我们将某个对象声明为了final的，那么我们将不能再改变这个对象的引用了。如果我们尝试将被修饰为final的对象重新赋值，编译器就会报错

这么简单的一个关键字，怎么需要强制修饰一个局部变量

局部变量

class文件

1
2
3
4
5
6
7
8
9

public static void main(String[] args) {
    String name = "Whoops bug";
    int pluginType = 3;
}

public void testFinal(){
    final String name = "Whoops bug";
    int pluginType = 3;
}

两个方法一个局部变量修饰为final,一个不修饰为final

通过javap查看字节码

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

public static void main(java.lang.String[]);
   Code:
      0: ldc           #2                  // String Whoops bug
      2: astore_1
      3: iconst_3
      4: istore_2
      5: return
   LineNumberTable:
     line 13: 0
     line 14: 3
     line 15: 5
   LocalVariableTable:
     Start  Length  Slot  Name   Signature
         0       6     0  args   [Ljava/lang/String;
         3       3     1  name   Ljava/lang/String;
         5       1     2 pluginType   I

 public void testFinal();
   Code:
      0: ldc           #2                  // String Whoops bug
      2: astore_1
      3: iconst_3
      4: istore_2
      5: return
   LineNumberTable:
     line 18: 0
     line 19: 3
     line 20: 5
   LocalVariableTable:
     Start  Length  Slot  Name   Signature
         0       6     0  this   Lcom/jack/lang/LocalFinalTest;
         3       3     1  name   Ljava/lang/String;
         5       1     2 pluginType   I

方法参数与局部变量用final修饰是纯编译时信息，到Class文件里就已经没有踪迹了，JVM根本不会知道方法参数或者局部变量有没有被final修饰

曾经的阿里巴巴规范提出：

推荐】final可提高程序响应效率，声明成final的情况：

（1）不需要重新赋值的变量，包括类属性、局部变量；

（2）对象参数前加final，表示不允许修改引用的指向；

（3）类方法确定不允许被重写

最新规范已经没有这种描述了，R大也回复过这个理由不成立，与性能无关

不变性

按上面class文件看，已经与性能无关，那么只能是它的本性：不变性

final is one of the most under-used features of Java. Whenever you compute a value and you know it will never be changed subsequently put a final on it. Why?

final lets other programmers (or you reviewing your code years later) know they don’t have to worry about the value being changed anywhere else.

If you get in the habit of always using final, when it is missing, it warns people reading your code there is a redefinition of the value elsewhere.

final won’t let you or someone else inadvertently change the value somewhere else in the code, often by setting it to null. final helps prevent or flush out bugs. It can sometimes catch an error where an expression is assigned to the wrong variable. You can always remove it later.

final helps the compiler generate faster code, though I suspect a clever compiler could deducing finality, even when the final is missing. final values can sometimes be in-lined as literals. They can be further collapsed at compile time in other final expressions.

I have got into the habit of using final everywhere, even on local variables and if I am in doubt, I use final on every declaration then take it off when the compiler points out that I modified it elsewhere. When I read my own code, a missing final is a red flag there is something complicated going on to compute a value.

If you reference a static final in another class, that value often becomes part of your class at compile time. The source class then need not be loaded to get the value and the source class need not even be included in the jar. This helps conserve RAM (Random Access Memory) and keep your jars small.

At the machine language level, static finals can be implemented with inline literals, the most efficient form of addressing data.

A little known feature of Java is blank finals. You can declare member variables final, but not declare a value. This forces all constructors to initialise the blank final variables. A final idiom

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

public void test() {
        // Use of final to ensure a variable is always assigned a value,
// and is assigned a value once and only once.
        int a = 4;
        final int x;

        if (a > 0) {
            x = 14;
        } else if (a < 0) {
            x = 0;
        } else {
            x = 3;
        }
        System.err.println(x);
    }

修饰为final是为了解决正确性、合理性、严谨性。用来提醒自己以及其他人，这里的参数/变量是真的不能被修改，并让Java编译器去检查到底有没有被乱改

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

public void testSwitch(){
    final String name;
    int pluginType = 3;
    switch (pluginType) {
        case 1:
            name = "Candidate Stuff";
            //break;
            //should have handled all the cases for pluginType
        case 2:
            name = "fff";
    }
    // code, code, code
    // Below is not possible with final
    //name = "Whoops bug";
}

如果switch遗漏了break，或者switch完整的，在外面给final变量再次赋值，编译器就会报错

类变量

对于final修饰的局部变量有了清晰的认识，再延伸一下final类变量

这儿涉及到一个问题,为什么JUC中很多的方法在使用类final变量时，都在方法中先引用一下

1
2
3
4
5
6
7
8
9
10
11
12
13
14

public class ArrayBlockingQueue<E> extends AbstractQueue<E>
        implements BlockingQueue<E>, java.io.Serializable {
        /** Main lock guarding all access */
    final ReentrantLock lock;
    
     public int remainingCapacity() {
        final ReentrantLock lock = this.lock;
        lock.lock();
        try {
            return items.length - count;
        } finally {
            lock.unlock();
        }
    }

Doug Lea给的答复是

It’s ultimately due to the fundamental mismatch between memory models
and OOP
Just about every method in all of j.u.c adopts the policy of reading fields as locals whenever a value is used more than once.This way you are sure which value applies when.This is not often pretty, but is easier to visually verify.
The surprising case is doing this even for “final” fields.This is because JVMs are not always smart enough to exploit the fine points of the JMM and not reload read final values, as they would otherwise need to do across the volatile accesses entailed in locking. Some JVMs are smarter than they used to be about this, but still not always smart enough.

翻译大意：

归根究底是由于内存模型与OOP之间的原则不一致。
几乎j.u.c包中的每个方法都采用了这样一种策略：当一个值会被多次使用时，就将这个字段读出来赋值给局部变量。虽然这种做法不雅观，但检查起来会更直观。
final字段也会做这样处理，可能有些令人不解。这是因为JVM并不足够智能，不能充分利用JMM已经提供了安全保证的可优化点，比如可以不用重新加载final值到缓存。相比过去，JVM在这方面有很大进步，但仍不够智能

1
2
3
4
5
6
7
8

private volatile Integer v1 = 1;


    public void test(){
        Integer a = v1;
        Integer b = v1;
        System.err.println(v1);
    }

看一下字节码

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

public class com.jack.lang.LocalFinalTest {
  private final java.lang.Integer v1;
    descriptor: Ljava/lang/Integer;
public void test();
    descriptor: ()V
    Code:
       0: aload_0
       1: getfield      #3                  // Field v1:Ljava/lang/Integer;
       4: astore_1
       5: aload_0
       6: getfield      #3                  // Field v1:Ljava/lang/Integer;
       9: astore_2
      10: getstatic     #4                  // Field java/lang/System.err:Ljava/io/PrintStream;
      13: aload_0
      14: getfield      #3                  // Field v1:Ljava/lang/Integer;
      17: invokevirtual #5                  // Method java/io/PrintStream.println:(Ljava/lang/Object;)V
      20: return

使用局部变量引用一下

1
2
3
4
5
6
7
8
9

private final Integer v1 = 1;


public void test(){
    final Integer v2 = v1;
    Integer a = v2;
    Integer b = v2;
    System.err.println(v2);
}

对应字节码

1
2
3
4
5
6
7
8
9
10
11
12
13
14

public void test();
descriptor: ()V
Code:
   0: aload_0
   1: getfield      #3                  // Field v1:Ljava/lang/Integer;
   4: astore_1
   5: aload_1
   6: astore_2
   7: aload_1
   8: astore_3
   9: getstatic     #4                  // Field java/lang/System.err:Ljava/io/PrintStream;
  12: aload_1
  13: invokevirtual #5                  // Method java/io/PrintStream.println:(Ljava/lang/Object;)V
  16: return

少了很多次的

1
2

0: aload_0
1: getfield

这就是Doug Lea所讲的没有充分利用JMM已经提供了安全保证的可优化点吗？

其实还有一个关键字与final类似，那就是volatile

1
2
3
4
5
6
7
8
9
10
11
12
13

private volatile FieldType field；  
   
 FieldType getField(){  
    FieldType result = field;  
    if(result == null){  // first check (no locking)  
       synchronized(this){  
          result = field;  
          if(result == null) // second check (with locking)  
             field = result = computeFieldValue();  
       }  
    }  
    return result;  
 }

在单例模式懒汉方式下，加个局部的result变量，会有25%性能会提高（effective java 2第71条）

这儿的性能提升，似乎也是这个原因

其实final和volatile还有更多的内存语义，禁止重排序。但在class文件中没有，使用hsdis与jitwatch查看JIT后的汇编码，可以发现一些端倪

1
2
3
4

0x0000000114428e3e: inc    %edi
0x0000000114428e40: mov    %edi,0xc(%rsi)
0x0000000114428e43: lock addl $0x0,(%rsp)     ;*putfield v1
                                ; - com.jack.lang.LocalFinalTest::test@9 (line 17)

在对volatile写操作时，会加上lock，就是内存屏障store指令

而对于final没有看到相应汇编语句

现在我们以 x86 处理器为例，说明 final 语义在处理器中的具体实现。
上面我们提到，写 final 域的重排序规则会要求译编器在 final 域的写之后，构造函数 return 之前，插入一个 StoreStore 障屏。读 final 域的重排序规则要求编译器在读 final 域的操作前面插入一个 LoadLoad 屏障。

由于 x86 处理器不会对写 - 写操作做重排序，所以在 x86 处理器中，写 final 域需要的 StoreStore 障屏会被省略掉。同样，由于 x86 处理器不会对存在间接依赖关系的操作做重排序，所以在 x86 处理器中，读 final 域需要的 LoadLoad 屏障也会被省略掉。也就是说在 x86 处理器中，final 域的读 / 写不会插入任何内存屏障！

既然没有相应内存屏障指令，那对于类变量加个局部变量，更大的理由就是少了aload、getfield指令

参考资料

final : Java Glossary

https://zhuanlan.zhihu.com/p/136819200

为什么分层

引用《领域驱动设计模式、原理与实践》

为了避免将代码库变成大泥球（BBoM）并因此减弱领域模型的完整性且最终减弱可用性，系统架构要支持技术复杂性与领域复杂性的分离。引起技术实现发生变化的原因与引起领域逻辑发生变化的原因显然不同，这就导致基础设施和领域逻辑问题会以不同速率发生变化

每一层都有各自的职责，显然这也是符合SRP的

如何分层

DDD的标准形态

1. User Interface是用户接口层，主要用于处理用户发送的Restful请求和解析用户输入的配置文件等，并将信息传递给Application层的接口
2. Application层是应用层，负责多进程管理及调度、多线程管理及调度、多协程调度和维护业务实例的状态模型。当调度层收到用户接口层的请求后，委托Context层与本次业务相关的上下文进行处理
3. Domain层是领域层，定义领域模型，不仅包括领域对象及其之间关系的建模，还包括对象的角色role的显式建模
4. Infrastructure层是基础实施层，为其他层提供通用的技术能力：业务平台，编程框架，持久化机制，消息机制，第三方库的封装，通用算法，等等

根据DDD细化业务逻辑层

模块

结合maven的module,项目中现在分了八个module

1
2
3
4
5
6
7
8
9
10

<modules>
    <module>generator-assist-dao</module> <!-- 生成的dao -->
    <module>generator-assist-client-api</module> <!-- swagger api yaml -->
    <module>assist-client-api</module> <!-- 生成的api -->
    <module>assist-controller</module> <!-- controller -->
    <module>assist-service</module> <!-- domain -->
    <module>assist-infrastructure</module> <!-- infrastructure -->
    <module>assist-common</module> <!-- 基础common -->
    <module>start</module> <!-- 启动入口及test -->
</modules>

start

入口模块

包结构：

• start 只有一个启动类
• test 单元测试

除了启动类，还有单元测试

generator-assist-dao

生成的dao类

包结构：

• repository
  • model 与数据库对应的实体类
• repository
  • mapper mybatis的mapper

现在实践落地时，这个模块是个空模块，why?

DDD中明确了repository概念，并属于domain层，但dao是对底层数据库的封装，具体实现类放在infrastructure层更合理

在COLA中，作者也是为了领域层的纯洁性，依赖反转了，repository接口定义在domain层，而实现在infra层

但在落地时，domain与infra出现了循环依赖，COLA把实现放在了app层，这样有些另类，所以暂时先把repository全部放在了service层

迷思：

1、基于mybatis的实现，mapper本身是接口，repository实现类放在domain层，不要接口，这样满足DDD分层规则，但离DIP差了一步

2、在《DDD之熵》中提过

DDD引入repository放在了领域层，一是对应聚合根的概念，二是抽象了数据库访问，，但DDD限界上下文可能不仅限于访问数据库，还可能访问同样属于外部设备的文件、网络与消息队列。为了隔离领域模型与外部设备，同样需要为它们定义抽象的出口端口，这些出口端口该放在哪里呢？如果依然放在领域层，就很难自圆其说。例如，出口端口EventPublisher支持将事件消息发布到消息队列，要将这样的接口放在领域层，就显得不伦不类了。倘若不放在位于内部核心的领域层，就只能放在领域层外部，这又违背了整洁架构思想

3、是不是有别的理论支撑解决问题2

generator-assist-client-api

为了生成api的swagger yaml文件

包结构：

• swagger-spec
  • all swagger所有yaml文件的整合文件
  • apis swagger定义的api
  • models swagger定义的api中的model
• swagger-templates 模板文件

assist-client-api

通过swagger生成的api接口与api中的model

包结构：

• client
  • api swagger生成的api接口
  • model swagger生成的request,response对象

assist-controller

controller层，放置controller

包结构：

• controller 所有的controller
• xxljob xxljob补偿任务

按DDD分层规范，controller属于ui层，处理restful请求

• 接受请求 —— 由spring提供能力
• 请求格式校验及转换 —— 格式校验遵循java Validation规范
• 权限校验 —— 由网关处理
• 路由请求 —— 网关处理
• 记录请求 —— 专门Accessfilter处理
• 回复响应 —— 由spring提供能力

为什么还有一个xxljob包，从能力区分，xxljob放到infra层才对。这个原因类似generator-assist-dao模块，xxljob的handler需要调用application service，需要依赖service module

因此可以把xxljob作为远程请求的一个入口，与controller一样归在ui层

这儿引出一点思考，controller真的是ui层吗？能划分到别的层吗？

有几种设计思路

1. ui层完全归属于大前端，不在后端，也就不在ddd中，后端都是从application service开始
2. controller归于ui
3. controller归于infra，controller毕竟是依赖具体底层框架能力的adapter

controller是基于springboot的具体实现

从上面的分析，可以看出controller逻辑上是归到infra层，但物理上不能放到infra模块；也不能简单把controller看作MVC中的C，还有很多像xxljob样的入口

1. 入口会有很多，如controller、xxljob，还有mq等等
2. 还有进程内的，如event，应用层，基础设施层，领域层都有event，怎么区分event是个问题
3. application serivce与domain service区分也常常给人带来烦恼

这儿是否可以借鉴《DDD之形》中的端口和适配器架构

把controller看作driving adapter，既然区分这么复杂，那可不可以简单点，加厚controller，整合入口与application service

简单点分成两部分：远程服务与本地服务

• 远程服务：定义会跨进程服务，分为资源（Resource）服务、供应者（Provider）服务、控制器（Controller）服务与事件订阅者（Event Subscriber）服务
• 本地服务：所有远程服务需要调用领域服务，必须经过本地服务才能调用；明确隔离外界与领域，防止领域模型外泄

assist-service

domain层，但现在还是三层结构的思路，什么类都有，app service，domain service，dto,event 甚至还有基础设施层类

包结构

• BO
• builder
• common
• component
• convertor
• domain
• dto
• event
• interceptor
• listener
• model
• repository
• service
• thrid
• valid

assist-infrastructure

基础设施层

包结构

• config 配置信息
• adapter 外部调用封装
  • clients 外部调用实现
  • pl 服务接口的契约 published language
• dp domain primitive 这是不是应该在domain层
• common 公共类，(InvoiceType与InvoiceTypeEnum的问题)
• event
  • publish 事件发布者，此包为空，直接依赖spring不需要自实现了
• exception 异常类
• gateway 网关，封装访问外部系统或资源行为的对象
  • wechat 外部名称
    • api 外接接口
    • dto 外接接口dto
• local
  • pl
• ports
  • clients 外部调用接口
• repository
  • model
• resources 资源
• service 依赖外部的service
• util 工具类

现在的包结构很丰富，最常见的包就是gateway，配合acl与外部交互

U表示上游（Upstream）的被依赖方，D表示下游（Downstream）的依赖方。防腐层（ACL）放在下游，将上游的消息转化为下游的领域模型

结合generator-assist-dao模块的问题，是否可以扩大ACL，而不仅限于gateway中,像资源库一样，不必完全遵循DDD只抽象repository，像访问第三方应用，缓存，消息都可以抽象出来，契合端口履行的职责一样

改造

1
2
3
4
5
6
7
8
9

<modules>
    <module>generator-assist-dao</module> <!-- 生成的dao -->
    <module>generator-assist-client-api</module> <!-- swagger api yaml -->
    <module>assist-client-api</module> <!-- 生成的api -->
    <module>assist-ohs</module> <!-- ohs -->
    <module>assist-service</module> <!-- domain -->
    <module>assist-acl</module> <!-- acl -->
    <module>start</module> <!-- 启动入口及test -->
</modules>

assist-controller

根据上面的分析，这一层可以更厚实些

改名为assist-ohs

OHS,open host service 开放主机服务，定义公开服务的协议，包括通信的方式、传递消息的格式（协议）

包结构

• remote
  • controller
  • openapi
  • xxljob
  • subscribe
• local
  • appservices
  • pl (plush language) request,response
  • convertor

assist-service

domain层

包结构

• domain 领域对象
• service 领域服务
• factory 领域对象工厂
• builder 领域对象构造器

assist-acl

扩大了基础设施层，隔离领域层与外部依赖，对所有外部环境一视同仁，无需针对资源库做特殊化处理，如此也可保证架构的简单性，repository、client、cahce…

领域层依赖port接口

包结构

• config 配置信息
• port 依赖外部接口
  • repository 数据库接口
  • client 第三方系统接口
  • publisher 消息接口
  • cache 缓存接口
• adapter port的具体实现
  • repository
  • pl
  • client

总结

模块划分以及包结构还只是一家之言，一是有充足的理论体系支撑，不管按DDD标准，还是变形，更多地有理有据，与团队、也与自己达成一致；二是domain的抽象，一切都是为了领域模型的稳定性和扩展性，形只是表象

我们这个项目还是太注重了形，最重要的domain还是过弱

根据上一篇【死锁分析】，又重新梳理了一下，画图表示更形象一些

update ? where user_id=? and tenant_id=? and no=?;如果先走（tenant_id,user_id） 则是日志一

先走no，则是日志二

索引交叉，则是日志三

最近借着死锁事项，又温习了部分数据库的理论知识，后面有时间再整理。现在的程序员真难，得上知天文，下知地理；这应该是DBA的专长，作为开发也得去深究，真难

在追查死锁的过程中，对照理论有一些实践，总结一下：

查看事务自动提交选项

1
2
3
4
5

show session variables like 'autocommit';
show global variables like 'autocommit’;

set session autocommit=0;
set global autocommit=0;

查看事务隔离级别

1

select @@tx_isolation

查看锁信息，想查看一条sql使用了什么锁，需要打开锁监听

1
2
3
4
5
6
7
8
9

show session variables like '%output%';

#开启InnoDB锁监控
set global innodb_status_output_locks=on;

set global innodb_status_output=on;
#上面的语句可定期写入到标准错误输出（stderr，即error log，大概每15s写一次），你也可以使用 SHOW ENGINE INNODB STATUS 语句直接在客户端获取innodb信息

show session variables like '%output%';

要启用InnoDB锁定监视器的 SHOW ENGINE INNODB STATUS输出，只需启用innodb_status_output_locks

打开监控开关后，在mysql日志文件中会出现

1
2
3
4
5
6
7

=====================================
2020-06-30 15:44:46 7fdc8a76e700 INNODB MONITOR OUTPUT
=====================================

----------------------------
END OF INNODB MONITOR OUTPUT
============================

打开锁监控，可以确定一下常用语句的锁信息

执行完一条SQL，使用SHOW ENGINE INNODB STATUS打印出锁信息

1
2
3
4

delete from invoice_collection_info where id=1275244823997059072

TABLE LOCK table `assist`.`invoice_collection_info` trx id 1636893 lock mode IX
RECORD LOCKS space id 18491 page no 211 n bits 104 index `PRIMARY` of table `assist`.`invoice_collection_info` trx id 1636893 lock_mode X locks rec but not gap

delete语句，根据主键删除操作；可以明显看出上了表锁IX model,还有一个主键索引锁

其实如果有二级索引，还会有二级索引锁，但那是隐式锁，所以没有显示出来，后面会有试验让隐式锁显示化

使用二级索引删除操作

1
2
3
4
5
6
7
8
9
10

delete FROM invoice_item WHERE ( collection_id = 1275244823997059072 );

TABLE LOCK table `assist`.`invoice_item` trx id 1636964 lock mode IX
RECORD LOCKS space id 18493 page no 4 n bits 784 index `idx_collection_id` of table `assist`.`invoice_item` trx id 1636964 lock_mode X locks rec but not gap
Record lock, heap no 563 PHYSICAL RECORD: n_fields 2; compact format; info bits 0
 0: len 8; hex 91b2946930001000; asc    i0   ;;
 1: len 8; hex 91b2ae5d61401000; asc    ]a@  ;;

RECORD LOCKS space id 18493 page no 12 n bits 96 index `PRIMARY` of table `assist`.`invoice_item` trx id 1636964 lock_mode X locks rec but not gap
Record lock, heap no 28 PHYSICAL RECORD: n_fields 23; compact format; info bits 0

先在二级索引上加锁，再在对应的主键索引上加锁

使用二级索引查询

1
2
3
4
5
6

select * from invoice_collection_info where invoice_uiq_flag = '031001900104-62079412' for update

TABLE LOCK table `assist`.`invoice_collection_info` trx id 1636947 lock mode IX
RECORD LOCKS space id 18491 page no 642 n bits 344 index `idx_uniflag` of table `assist`.`invoice_collection_info` trx id 1636947 lock_mode X locks rec but not gap

RECORD LOCKS space id 18491 page no 496 n bits 96 index `PRIMARY` of table `assist`.`invoice_collection_info` trx id 1636947 lock_mode X locks rec but not gap

从日志中看出，先在invoice_uiq_flg二级索引上加锁，再在主键索引加锁

使用主键更新操作

1
2
3
4

update invoice_collection_info set invoice_uiq_flag = '031200190010-62079412' WHERE (  id = 1275244823997059072 );
 
TABLE LOCK table `assist`.`invoice_collection_info` trx id 1636958 lock mode IX
RECORD LOCKS space id 18491 page no 741 n bits 88 index `PRIMARY` of table `assist`.`invoice_collection_info` trx id 1636958 lock_mode X locks rec but not gap

其实不仅会在主键加X，还会在二级索引上也加X，但没有显示出来；这儿跟delete一样，其实也是个隐式锁

模拟测试了一下，两条sql，一条根据二级索引删除操作、另一条使用主键更新记录模拟并发死锁，把update中的二级索引锁显示出来了

上面的操作都是在RC级别下进行的，对于select操作，快照读都不会加锁，实验结果也与理论一致

最近新项目上线，在压测和发布生产都出现了好几种死锁情况，分析一二

死锁日志

日志一：

日志二：

日志三：

这三个死锁日志特别的有意思，都是同一条SQL，但各种组合样的死锁都齐活了

日志一的两条sql，where里面的条件不同；

日志二和日志三sql完全一样，其实是两次调用(同一时刻并发调用)，调用条件不同，但在程序处理时这条SQL的where条件一样而已

分析

隔离级别RC

日志一，where里面的条件不同

第一个事务在等待RECORD LOCKS，锁模式为X model;位置在space id 428 page no 178

第二个事务持有RECORD LOCKS，锁模式为X model;位置也在space id 428 page no 178；等待的锁也是RECORD LOCKS，锁模式为X model，也在space id 428 page no 178

这个死锁很是奇怪，同一条sql，都是在索引【idx_tenant_user】上加锁，完全不符合死锁的循环等待特征

这张表上的索引

1
2
3

KEY `idx_collection_no` (`collection_no`) USING BTREE,
KEY `idx_uniflag` (`invoice_uiq_flag`) USING BTREE,
KEY `idx_tenant_user` (`tenant_id`,`user_id`) USING BTREE

通过explain查看此语句

索引上看使用idx_tenant_user,也与死锁日志一致，但怎么就死锁了呢？

【SHOW ENGINE INNODB STATUS;】只能显示最终发生死锁时的sql,并不能显示全部的sql，从程序上下文中寻找，发现点蛛丝马迹

事务2在T1时刻执行了一条根据id更新数据的sql，这条sql会在id聚簇索引上加X锁，还会在二级索引上加X锁，所以先获得了(user_id,tenant_id)锁，

事务1在T2时刻只能等待

事务2在T3时刻形成了循环等待，deadlock

日志二,sql完全一样

与前面解释，两个并发请求，入参不同，但到这个方法时，sql的条件是一样的

日志三，sql也完全一样

虽然与日志二的SQL一样，但死锁日志却不同

为什么同样的SQL，却得出各样的结果？时而collection_no索引在前，时而组合索引在前

苦思几日，在线上跑了下explain，发现了些问题

原来线上使用的index merge

有官网上有介绍：https://dev.mysql.com/doc/refman/5.6/en/index-merge-optimization.html

MySQL在分析执行计划时发现走单个索引的过滤效果都不是很好，于是对多个索引分别进行条件扫描，然后将多个索引单独扫描的结果进行合并的一种优化操作。合并的方式分为三种：intersection、union和sort_union

index merge 之 intersect,简单而言，index intersect merge就是多个索引条件扫描得到的结果进行交集运算。显然在多个索引提交之间是 AND 运算时，才会出现 index intersect merge.

正因为index merge,所以索引的真正执行顺序是不一样的，也就造成了各种表象

解决

建立联合索引

都使用主键更新

关掉参数index_merge_intersection=off，禁用index_merge功能

参照

MySQL 优化之 index_merge

一个 MySQL 死锁案例分析

早时总结过《ThreadLocal解析》、《FastThreadLocal解析》

最近看些资料时，又注意到这个类，不尽想再重温下，很多知识点，之前已经总结了，此篇主要有两个问题：

1、弱引用的意义

2、如何防key冲突

弱引用

ThreadLocal底层使用的ThreadLocalMap一直在进化中，早在JDK1.3时代还是使用的普通的HashMap，后来才改写成ThreadLocalMap

这个ThreadLocalMap有两个特殊之处，一是使用了线性探索法，详情见《Hashmap源码解析》；二是key使用了弱引用

1
2
3
4
5
6
7
8
9
10
11

/**
 * ThreadLocalMap is a customized hash map suitable only for
 * maintaining thread local values. No operations are exported
 * outside of the ThreadLocal class. The class is package private to
 * allow declaration of fields in class Thread.  To help deal with
 * very large and long-lived usages, the hash table entries use
 * WeakReferences for keys. However, since reference queues are not
 * used, stale entries are guaranteed to be removed only when
 * the table starts running out of space.
 */
static class ThreadLocalMap{}

从注释可以看出作者为什么使用弱引用，为了处理大对象和长周期对象，在GC时可以主动回收

一直感觉这儿的弱引用设计是个鸡肋

在实际使用中，还是会出现内存泄漏，何必使用弱引用呢？

在ThreadLocal的类注释中

1
2
3
4
5
6

This class provides thread-local variables.  These variables differ from
 * their normal counterparts in that each thread that accesses one (via its
 * {@code get} or {@code set} method) has its own, independently initialized
 * copy of the variable.  {@code ThreadLocal} instances are typically private
 * static fields in classes that wish to associate state with a thread (e.g.,
 * a user ID or Transaction ID).

建议使用static修饰

阿里规范也有此建议：

【参考】ThreadLocal 对象使用 static 修饰，ThreadLocal 无法解决共享对象的更新问题。 说明:这个变量是针对一个线程内所有操作共享的，所以设置为静态变量，所有此类实例共享此静态变量， 也就是说在类第一次被使用时装载，只分配一块存储空间，所有此类的对象(只要是这个线程内定义的)都可 以操控这个变量。

在 stackflow上点赞比较多的回答：

Because if it were an instance level field, then it would actually be “Per Thread - Per Instance”, not just a guaranteed “Per Thread.” That isn’t normally the semantic you’re looking for.

Usually it’s holding something like objects that are scoped to a User Conversation, Web Request, etc. You don’t want them also sub-scoped to the instance of the class.
One web request => one Persistence session.
Not one web request => one persistence session per object.

结合实际项目中都是使用线程池的，所以线程基本也是常驻内存的，根据建议使用static修饰，根本没有被回收的机会，虽是弱引用，但一直被强引用

所以何必呢，还让这个点成为一个常备的面试题，同是程序员，非得难为自己人呢！

上面的结论其实还是从大多数人的思维方式思考的，就是提到ThreadLocal都会与线程联系上，在线程的背景里讨论ThreadLocal

但从类注释上看，它是个变量：This class provides thread-local variables，所以还是从变量角度考虑

从变量范围讲，有类变量，局部变量，那ThreadLocal就是线程范围内的变量

根据变量的作用域，可以将变量分为全局变量，局部变量。简单的说，类里面定义的变量是全局变量，函数里面定义的变量是局部变量。

还有一种作用域是线程作用域，线程一般是跨越几个函数的。为了在几个函数之间共用一个变量，所以才出现：线程变量，这种变量在Java中就是ThreadLocal变量。

全局变量，范围很大；局部变量，范围很小。无论是大还是小，其实都是定死的。而线程变量，调用几个函数，则决定了它的作用域有多大。

ThreadLocal是跨函数的，虽然全局变量也是跨函数的，但是跨所有的函数，而且不是动态的。

ThreadLocal是跨函数的，但是跨哪些函数呢，由线程来定，更灵活

1
2
3
4
5
6
7
8
9
10
11

public class ThreadLocalDemo
{
	public static void main(String[] args)
	{
		ThreadLocal<Integer> count = new ThreadLocal<Integer>();
		//使用count
		count.set(10);
		// count不再被使用，可以进行内存回收
		System.out.println("");
	}
}

这个示例中，count要不要被回收

我想，此时JDK的作者也是左右为难，从眼见为实的角度来说，变量不用了就应该进行回收，实现内存的自动回收，这是Java给人最大的特点。

但是，此时不能回收count，因为它与10绑定到了一块，而且只能通过count才能读写10。最后JDK作者耍了一个小聪明，用弱引用包装了count，没有干脆利索的进行内存回收，而是拖拖拉拉的进行回收，反正，最后实现了变量不用就回收的基本原则，与Java的传统思想一脉相承

到此，应该是知道为什么作者要设计为弱引用了，按建议使用ThreadLocal,修饰为static,就不是为了防内存泄漏，而只是为了达到java变量不使用就回收的基本原则，只是在线程范围时，只能曲线救国了

防碰撞

在hash数据结构中，最重要的一点就是如何更好地设计，尽量避免key的冲突

普通的hashmap使用的是拉链法，把长度设置成2的N次方，还有负载因子

ThreadLocalMap使用的线程探索法，作者使用了哪些奇技淫巧

map的长度

1
2
3
4

/**
 * The initial capacity -- MUST be a power of two.
 */
private static final int INITIAL_CAPACITY = 16;

ThreadLocalMap没有设置容量的方法，一般情况下，也不会实例化那么多ThreadLocal实例

必须是2的N次方，这个特性在HashMap中一样，就不解释了，详情见《Hashmap源码解析》

负载因子

在hashmap中，默认负载因子为了0.75，在ThreadLocal中呢？

1
2
3
4
5
6

/**
 * Set the resize threshold to maintain at worst a 2/3 load factor.
 */
private void setThreshold(int len) {
    threshold = len * 2 / 3;
}

看出负载因子为2/3

但threadlocalmap还有特别的地方，就是弱引用，key可能变成null，所以在get,set都会清理key为null的Entry

1
2
3
4

tab[i] = new Entry(key, value);
int sz = ++size;
if (!cleanSomeSlots(i, sz) && sz >= threshold)
    rehash();

再看rehash();

1
2
3
4
5
6
7
8
9
10
11
12

/**
 * Re-pack and/or re-size the table. First scan the entire
 * table removing stale entries. If this doesn't sufficiently
 * shrink the size of the table, double the table size.
 */
private void rehash() {
    expungeStaleEntries();

    // Use lower threshold for doubling to avoid hysteresis
    if (size >= threshold - threshold / 4)
        resize();
}

rehash方法并不是直接就rehash了，会先清理过期元素，再判断size>= threshold-threshold/4

threshold=len * 2 / 3

threshold-threshold/4=len 2 / 3-(len 2 / 3)/4= len/2

所以最终是在清理过期元素后，元素数量超过len/2时，就会正式扩容两倍

0x61c88647

hash函数的设计是hash类数据结构的一个重点，空间与时间的平衡是关键

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

/**
 * ThreadLocals rely on per-thread linear-probe hash maps attached
 * to each thread (Thread.threadLocals and
 * inheritableThreadLocals).  The ThreadLocal objects act as keys,
 * searched via threadLocalHashCode.  This is a custom hash code
 * (useful only within ThreadLocalMaps) that eliminates collisions
 * in the common case where consecutively constructed ThreadLocals
 * are used by the same threads, while remaining well-behaved in
 * less common cases.
 */
private final int threadLocalHashCode = nextHashCode();

/**
 * The next hash code to be given out. Updated atomically. Starts at
 * zero.
 */
private static AtomicInteger nextHashCode =
    new AtomicInteger();

/**
 * The difference between successively generated hash codes - turns
 * implicit sequential thread-local IDs into near-optimally spread
 * multiplicative hash values for power-of-two-sized tables.
 */
private static final int HASH_INCREMENT = 0x61c88647;

/**
 * Returns the next hash code.
 */
private static int nextHashCode() {
    return nextHashCode.getAndAdd(HASH_INCREMENT);
}

每当创建ThreadLocal实例时这个值都会累加 0x61c88647

0x61c88647转化成十进制：2654435769为32位无符号整数的黄金分割值，而-1640531527就是32位带符号整数的黄金分割值

当容量为2的N次方，并且使用上这个魔法值后，元素经过散列算法后恰好填充满了整个容器，也就是实现了完美散列

对于这个数字由来，我也大致搜索了些资料，这已经超出作为一名码农的能力范围，只能反思数学老师讲的：不是数学用不上，而是你没有用上的能力

环形

1
2
3
4
5
6
7
8
9
10
11
12
13

/**
 * Increment i modulo len.
 */
private static int nextIndex(int i, int len) {
    return ((i + 1 < len) ? i + 1 : 0);
}

/**
 * Decrement i modulo len.
 */
private static int prevIndex(int i, int len) {
    return ((i - 1 >= 0) ? i - 1 : len - 1);
}

在寻找下一个位置时，虽然threadlocalmap是线性探索，但逻辑上使用环形结构，这个与防冲突关系不大，但也是个知识点，一并罗列下

参考

一针见血 ThreadLocal

Why 0x61c88647?

ThreadLocal源码——黄金分割数的使用

《DDD之形》把当前一些流行的架构给通览了一篇，那是不是万事大吉，随便挑一个形态实践就行呢？

正常情况对于有追求的程序员来讲，肯定不行，有两个原因

一因为完美，人人都是想要完美，每个架构实践都不是完美的，尤其离开业务场景去探讨架构，会使架构没法落地；因此你小抄的时候会变形，想把原先至少不太好的地方改得相对好些，但这样可能造成四不像

二因为没有意的形，只知其形，不得其意，必然会东施效颦；类似于第一点，完美，何为完美，还是得根据自身经验理解程序得出的结论，如果高度不够必然会画蛇添足

标准形态

根据DDD的理论，或者说DDD带来的优势，将三层架构进行演化，把业务逻辑层再细拆分成三层：应用层、领域层和基础设施层

分离业务逻辑与技术细节

DDD的标准形态

分层架构分为两种：严格分层架构和松散分层架构

严格分层，某层只能与直接位于其下方的层发生耦合；松散分层，允许任意上方层与任意下方层发生耦合

1. User Interface是用户接口层，主要用于处理用户发送的Restful请求和解析用户输入的配置文件等，并将信息传递给Application层的接口
2. Application层是应用层，负责多进程管理及调度、多线程管理及调度、多协程调度和维护业务实例的状态模型。当调度层收到用户接口层的请求后，委托Context层与本次业务相关的上下文进行处理
3. Domain层是领域层，定义领域模型，不仅包括领域对象及其之间关系的建模，还包括对象的角色role的显式建模
4. Infrastructure层是基础实施层，为其他层提供通用的技术能力：业务平台，编程框架，持久化机制，消息机制，第三方库的封装，通用算法，等等

DIP

上面的标准形态图形的左半边图，跟以往的很不一样，但从DIP角度看，低层服务应该依赖于高层组件

这是COLA2.0的分层，作者利用DIP对1.0版本进行了优化

1、核心业务逻辑和技术细节相分离，使用DIP，让Infrastructure反向依赖Domain

2、将repository上移到application层，把组装entity的责任转移到application

到此一切都很常规，很标准，但在落地时有几个问题：

一、Controller是哪一层，user interface层？还是infrastructure层？

这好像不是个问题，一般都放在user interface层，负责向用户展现信息以及解释用户命令；但细想一下，我们的controller都是基于底层框架，是框架提供的能力，那理论上放在infrastructure更合理一些。

二、再细化的架构元素放哪里？

其实这只是分层的大体方向，还有更细节的元素，在实践DDD的过程中，最常见的问题就是元素到底放在哪儿，比如Event,有各样的event，eventHandler，应用层、领域层都有，怎么区分呢？貌似回到了怎么区分应用服务与领域服务；还有各处javabean，哪些层能复用，谁复用谁

再比如COLA2.0，单从层次依赖图明显形成了循环依赖，落地不了；但作者把repository上移到了application层，又有些走不寻常路，一般来讲repository是放在domain层

如何办呢？大方向有了，但到小细节时，又有各种困惑，《SOLID之DIP》文中提到，分层至少有两层，一是业务领域层，二是其它层

这就是端口和适配器架构，可以算是六边形的简化版，但也从整体方向分成了两层，对应用层与用户接口层以及基础设施层进行了合并，无论是接受请求，还是输出数据都是gateway

但六边形架构仅仅区分了内外边界，提炼了端口与适配器角色，并没有规划限界上下文内部各个层次与各个对象之间的关系；怎么破？

这似乎是两个矛盾体，标准的层次分明了，但还是有些不确定性，对象放在哪个包不明确；而端口与适配器架构又太粗放；如何平衡？

本质上，领域驱动设计的限界上下文同样是对软件系统的切割，依据的关注点主要是根据领域知识的语境，从而体现业务能力的差异。在进入限界上下文内部，我们又可以针对限界上下文进行关注点的切割，并在其内部体现出清晰的层次结构，这个层次遵循整洁架构

根据张逸老师DDD课程中的案例

• 领域层：包含 PlaceOrderService、Order、Notification、OrderConfirmed 与抽象的 OrderRepository，封装了纯粹的业务逻辑，不掺杂任何与业务无关的技术实现。
• 应用层：包含 OrderAppService 以及抽象的 EventBus 与 NotificationService，提供对外体现业务价值的统一接口，同时还包含了基础设施功能的抽象接口。
• 基础设施层：包含 OrderMapper、RabbitEventBus 与 EmailSender，为业务实现提供对应的技术功能支撑，但真正的基础设施访问则委派给系统边界之外的外部框架或驱动器

重新审视六边形架构，匹配分层架构，两者可以融合

位于六边形边线之上的出口端口就应该既不属于领域层，又不属于基础设施层。它的职责与属于应用层的入口端口也不同，因为应用层的应用服务是对外部请求的封装，相当于是一个业务用例的外观

DDD引入repository放在了领域层，一是对应聚合根的概念，二是抽象了数据库访问，，但DDD限界上下文可能不仅限于访问数据库，还可能访问同样属于外部设备的文件、网络与消息队列。为了隔离领域模型与外部设备，同样需要为它们定义抽象的出口端口，这些出口端口该放在哪里呢？如果依然放在领域层，就很难自圆其说。例如，出口端口EventPublisher支持将事件消息发布到消息队列，要将这样的接口放在领域层，就显得不伦不类了。倘若不放在位于内部核心的领域层，就只能放在领域层外部，这又违背了整洁架构思想

DDD现在已然变成哲学，正因为是哲学，所以法无定法，到底怎么具体怎么实施，各显神通，心法固然重要，但心法有几人能真正领悟，一说就懂，一问就不会，一讨论就吵架；所以还是从外形看看，收集一些实践后的形态，由表入里，以形学形，慢慢品

看下面两个分层，左边是Vaughn Vernon 在《实现领域驱动设计》一书中给出了改良版的分层架构，他将基础设施层奇怪地放在了整个架构的最上面；右边就是DDD最标准的分层形态

形一

这是DDD专家张逸老师形态之一，除了controller在gateway中，其它还算常态

• ecommerce
  • core
    • Identity
    • ValueObject
    • Entity
    • DomainEvent
    • AggregateRoot
  • controllers
    • HealthController
    • MonitorController
  • application（视具体情况而定）
  • interfaces
    • io
    • telnet
    • message
  • gateways
    • io
    • telnet
    • message
  • ordercontext
    • application
    • interfaces
    • domain
    • repositories
    • gateways
  • productcontext
    • application
    • interfaces
    • domain

除了限界上下文自身需要的基础设施之外，在系统架构层面仍然可能需要为这些限界上下文提供公共的基础设施组件，例如对 Excel 或 CSV 文件的导入导出，消息的发布与订阅、Telnet 通信等。这些组件往往是通用的，许多限界上下文都会使用它们，因而应该放在系统的基础设施层而被限界上下文重用，又或者定义为完全独立的与第三方框架同等级别的公共组件。理想状态下，这些公共组件的调用应由属于限界上下文自己的基础设施实现调用。倘若它们被限界上下文的领域对象或应用服务直接调用（即绕开自身的基础设施层），则应该遵循整洁架构思想，在系统架构层引入 interfaces 包，为这些具体实现定义抽象接口

controller被放到了gateway中，包含远程调用，数据库；所有对外的接口都属于一种网关

形二

cola在github开源，作者模块与包划分，每个架构元素都很明确

controller

这是一个可选层，正如《分层架构》所讲，现在的框架都已经帮助从底层的具体HttpRequest转换成了requestDto，很多时候都是透传service，而像thrift类的框架，为了透明化入口，需要转换一下，

包

xxx.controller

client

二方库，里面存放RPC调用的DTO

包

xxx.api:存放应用对外接口

xxx.dto.domainmodel：数据传输的轻量级领域对象

xxx.dto.domainevent:数据传输的领域事件

application

应用层

包

xxx.service：接口实现的facade，没有业务逻辑，可以对应不同的adapter

xxx.event.handler:处理领域事件

xxx.interceptor:对所有请求的AOP处理机制

domain

领域层

包

xxx.domain:领域实现

xxx.service:领域服务，用来提供更粗粒度的领域能力

xxx.gateway:对外依赖的网关接口，包括存储、RPC等

infrastructure

基础层

包

xxx.config:配置信息相关

xxx.message:消息处理相关

xxx.repository:存储相关，gateway的实现类，主要用来做数据的CRUD操作

xxx.gateway:对外依赖网关接口(domain里面的gateway)的实现

形三

这是张逸老师课程的又一形态

六边形架构仅仅区分了内外边界，提炼了端口与适配器角色，并没有规划限界上下文内部各个层次与各个对象之间的关系；而整洁架构又过于通用，提炼的是企业系统架构设计的基本规则与主题。因此，当我们将六边形架构与整洁架构思想引入到领域驱动设计的限界上下文时，还需要引入分层架构给出更为细致的设计指导，即确定层、模块与角色构造型之间的关系

这是老师最新总结的菱形对称架构

南向网关引入了抽象的端口来隔离内部领域模型对外部环境的访问。这一价值等同于上下文映射的防腐层（Anti-Corruption Layer，简称为 ACL） 模式，只是它扩大了防腐层隔离的范围

形态四

该架构由端口和适配器组成，所谓端口是应用的入口和出口，在许多语言中，它以接口的形式存在

Martin Fowler将“封装访问外部系统或资源行为的对象”定义为网关（Gateway），在限界上下文的内部架构中，它代表了领域层与外部环境之间交互的出入口，即：

gateway = port + adapter

这个形态，简单入里，算是菱形对称架构的简易形，甚至可以说是菱形的初形

driving adapter + domain + driven adapter

总结

形态之多，背后的理论支撑之丰富，可见DDD的博大精深，谁能说是正宗，就算是Eric Evans都要怀疑人生，但不迷信，没有银弹。自己实践的才是最合适的

从年初就开始温习SOLID原则，原则看似很简单，有些其实就是一句话，但对照这些原则去观看自己的过往代码，还是很多违背这些原则的，诚然，没有完美的实践，但需要保持在走向完美的路上

当然，如果你说天天在CRUD，从没有用到过这些原则，这就是另一个话题了

最近就写了一段很臭的代码，反省一下

1
2
3
4
5
6
7
8
9
10

public AbstractInvoice(InvoiceCode invoiceCode, InvoiceNo invoiceNo, PaperDrewDate paperDrewDate, CheckCode checkCode) {
    this.invoiceCode = invoiceCode;
    this.invoiceNo = invoiceNo;
    this.paperDrewDate = paperDrewDate;
    if (checkCode instanceof VerifyCheckCode) {
        this.checkCode = checkCode.toNormal();
    } else {
        this.checkCode = checkCode;
    }
}

这段代码很简单，业务是发票，一张发票由基本的几个要素组成：发票代码、发票号码、开票时间、检验码、金额

形象点，找个平常普通发票的票样

其次，这是一个抽象类，构建时带有发票几票素，这些InvoiceCode,InvoiceNo,PaperDrewDate,CheckCode都是简单的Primitive Domain(不了解这个概念也没关系，下回分解；简单讲就是业务自包含的基本类型)

完整的抽象类关系

但代码里面用到了instanceof，当用到这个关键字，而且是在抽象实体时，基本上可以断定是抽象的层次不够，
可能违背了LSP

LSP原则很明了：子类可以随时替换父类；这儿用了instanceof，说明有不可替换的成份在

再追看CheckCode的层次

一个简单的校验码，为什么也要抽象成这样？

1
2
3
4
5
6
7
8
9
10
11

public abstract class CheckCode {

    protected String checkCode;

    public CheckCode(String checkCode) {
        this.checkCode = checkCode;
    }
    
    public CheckCode(int length, String checkCode, boolean isNumeric) {
    }
}

校验码有几种形式

1. 标准的20位长度的完整检验码
2. 后6位简短的检验码，发票做验真业务时使用
3. 区块链发票的检验码，5位长度，字母数字组合

因为有三种形态，不同的长度就是不同的类型；验真时只需要简短检验码；查看完整信息时需要完整的检验码

在发票接口中，也有相应的获取行为，也正因为有这种形为，需要在创建发票对象时，把VerifyCheckCode转换成NormalCheckCode

1
2
3
4
5

public interface Invoice {

    public CheckCode getCheckCode();
    
    public String getVerifyCheckCode();

这儿有个疑问，为什么不在构建发票前，把verifyCheckCode转成normalCheckCode，而不是到Invoice的构建内部再转化，那也就没有instanceof的事

但再细想，对于发票来讲，其实只有一个checkCode属性，没有VerifyCheckCode，那只是在请求验真时的一种形态，所以在发票对象中，不应该有verifyCheckCode属性

所以Invoice对象应该是这样

1
2
3
4
5
6
7
8
9
10
11

public interface Invoice {

    public CheckCode getCheckCode();
}

public AbstractInvoice(InvoiceCode invoiceCode, InvoiceNo invoiceNo, PaperDrewDate paperDrewDate, CheckCode checkCode) {
        this.invoiceCode = invoiceCode;
        this.invoiceNo = invoiceNo;
        this.paperDrewDate = paperDrewDate;
        this.checkCode = checkCode;
}

对于primitive domain,CheckCode自包含中应该带有verifyCheckCode

每一种CheckCode都有各自不同的行为

一般通过instanceof判断子类型时，都有不满足LSP的嫌疑；在这个场景中也差不多，但抓住了这一点，重新思考一下，类层次与结构行为可以设计得更合理

接口隔离原则，ISP，Interface Segregation Principle

用于处理胖接口（fat interface）所带来的问题。如果类的接口定义暴露了过多的行为，则说明这个类的接口定义内聚程度不够好

第一种定义: Clients should not beforced to depend upon interfaces that they don’t use.

客户端不应该依赖它不需用的接口

第二种定义：The dependency of oneclass to another one should depend on the smallest possible interface。

类间的依赖关系应该建立在最小的接口上

ISP还是比较简单的，通过行为分离，达到高内聚效果

不遵循ISP

类A依赖接口I中的方法1、方法2、方法3，类B是对类A依赖的实现。类C依赖接口I中的方法1、方法4、方法5，类D是对类C依赖的实现。

对于类B和类D来说，虽然他们都存在着用不到的方法（也就是图中红色字体标记的方法），但由于实现了接口I，所以也必须要实现这些用不到的方法

显然接口I是个胖接口，客户端依赖了他不需要用的接口方法

遵循ISP

将原有的接口I拆分为三个接口，类A不需要用到“方法4”和“方法5”，就可以选择不依赖接口I3

实例

设计一个门接口，它包含了一款自动门所需要的功能，开关，自动关闭等。

但是并不是每个门都有自动关闭的功能，所以timeOut超时这个方法放在该接口中，就会导致所有实现这个接口的子类都会默认的继承了这个方法，哪怕子类中不对这个方法做处理。

把接口拆分成2个，拆分成Door和TimeClient，2个接口，这样Door就只保持原有的基本功能，而timeOut超时的方法则放到TimeClient接口中，这样就可以解决上述中接口臃肿的问题

VS SRP

很多人会觉的接口隔离原则跟之前的单一职责原则很相似，其实不然

其一，单一职责原则原注重的是职责；而接口隔离原则注重对接口依赖的隔离。

其二，单一职责原则主要是约束类，其次才是接口和方法，它针对的是程序中的实现和细节；而接口隔离原则主要约束接口接口，主要针对抽象，针对程序整体框架的构建

在单一职责原则中，一个接口可能有多个方法，提供给多种不同的调用者所调用，但是它们始终完成同一种功能，因此它们符合单一职责原则，却不符合接口隔离原则，因为这个接口存在着多种角色，因此可以拆分成更多的子接口，以供不同的调用者所调用。

比如说，项目中我们通常有一个Web服务管理的类，接口定义中，我们可能会将所有模块的数据调用方法都在接口中进行定义，因为它们都完成的是同一种功能：和服务器进行数据交互；但是对于具体的业务功能模块来说，其他模块的数据调用方法它们从来不会使用，因此不符合接口隔离原则

架构

在一般情况下，任何层次的软件设计如果依赖于不需要的东西，都会是有害。

从源代码层次来说，这亲的依赖关系会导致不必要的重新编译和重新部署

对更高层次的软件架构设计来说，问题也类似

如果D中包含了F不需要的功能，那么这些功能同样也会是S不需要的。对D中这些功能的修改会导致F需要被重新部署，后者又会导致S的重新部署。

更糟糕的是，D中一个无关功能的错误也可能会导致F和S运行出错

TIPS

采用接口隔离原则对接口进行约束时，要注意以下几点：

• 接口尽量小，但是要有限度。对接口进行细化可以提高程序设计灵活性是不挣的事实，但是如果过小，则会造成接口数量过多，使设计复杂化。所以一定要适度。
• 为依赖接口的类定制服务，只暴露给调用的类它需要的方法，它不需要的方法则隐藏起来。只有专注地为一个模块提供定制服务，才能建立最小的依赖关系。
• 提高内聚，减少对外交互。使接口用最少的方法去完成最多的事情。

运用接口隔离原则，一定要适度，接口设计的过大或过小都不好。设计接口的时候，只有多花些时间去思考和筹划，才能准确地实践这一原则

Reference

《整洁架构之道》

Interface Segregation Principle(ISP)–接口隔离原则