今天记录的是一个关于沟通重要性的一件事。我们的Arch 2.0上线了，由于下层是DO，上层尚未形成业务的微服务，所以导致上层业务部门没有自己的代码库，所以有了引进一个业务模块的想法。
顺着老板们的想法，我提议了一个方案，命名为Storage Abstract Layer，然后发布给少部分人阅读讨论。某一天，听到我们的海x同学很不满意，让我很诧异。当然他那不满意的表情以及言语，导致我也不满意他的言论。一开始，我还在想，海某不能这样吧，也没有和我沟通过就如此下结论，不免太武断了。
又一天，我觉得这个事为什么不是我主动去找他呢？所以约上海某讨论了一番。误解往往是那么的蹊跷就由于一些小的误解造成的。原来确实是我自己的表达不到位。从海某的理论理解里，abstract layer是面向过程的一个术语，意思为抽象出一个新的层次。所以如果抽象出另外一个层次的话，势必造成架构的复杂性以及代码的复杂性，那他不乐意也是正常的。
海某提起的三种架构的思想，
1. 面向过程，可以提前抽象接口，在同一的内存下，任然是一层一层的调用的
2. 面向对象，这种架构下，我们有抽象，继承，多态；有设计模式等
3. 微服务，这种架构下，业务其实是一种workflow， 每个微服务提供的服务接口组成大的业务流程的某一个状态。所以海某提到了有限状态机
所以基于海某的这个理解来讲，基于我们的微服务框架，搞出一个Layer来讲，是觉得不可思议的事。
但是我想表达的意思却不是这样。我的意思是把Storage相关的内容聚集在一起，统一管理，统一把控质量。我的提议里根本不是基于面向过程的。所以经过友好的，细致的讨论，我们达成了一致。
最终的结果是，我将我的提议的标题改为Storage Service，这样确实减少了误解。当别人可能误解你的时候，不要认定了是别人误解了，耐心友好的沟通可以在这种情况下解决问题。
