逝去的七月

七月的成长

七月过得挺好，再也没有频繁的短信了，感觉万籁俱寂，心情无比舒畅。

六七月技术有哪些进步呢？

这些进步主要集中在运用上：
1、消息
2、dubbo调用配置
3、一些设计思想
4、看完了《实现领域驱动设计》

一、消息

模型变更，通过EventBus publish出去一个Event，这个Event就是变更后的Entity。通过DomainEvent实现监听，监听后可以有2种处理方式：

1）通过线程内事件直接调用服务层接口处理；
2）发送消息，异步处理。

1）线程内事件处理
实现了业务方法和监听的解耦。

Eg：updateDoctorInfo(String doctorId)接口调用后，doctor_info中的point发生变化，此时发出了一个事件，把事件发出去就可以了，不用处理监听后的逻辑，无论以后业务如何变化，只需要增加eventListener即可。这样接口updateDoctorInfo(String doctorId)只关注自己的事情——更新doctorInfo信息，其他不用管。

再通俗点讲：你变更了手机号，发一个朋友圈（Event），你不用关注看到你这条朋友圈的人怎么做，发出去就可以了。看到的人（evetListener）怎么做，是他们的事情，有的会存下来，有的会忽略掉，你不care.这样你换手机号和大家看到朋友圈（收到消息）之后采取的措施是解耦的。

2）异步消息

异步消息采用Transimitter监听Event，然后sendMessage(Message message)
伪代码如下：

Map<String,Object> body = Maps.newHashMap<>();
body.put("caseId",case);
body.put("creator",userInfoDTO);
String topic = Constants.CASE_EVENT_TOPIC_NAME;
String messageType  = messageType;
JsonMessage message = new JsonMessage(topic,messageType,body);
message.setBizKey(caseId);
messageService.send(message);

异步监听messageListener通过messageType监听消息，监听后处理对应的业务逻辑。

这个机制可以确保在看代码时候，可以清楚的知道数据流。某个操作会影响到哪里，影响范围有多广，是非常清晰的。

二、dubbo配置

微服务中的模块调用，比如：bfd模块调用tsp模块，
bfd的service直接使用tsp打包后的api-client，使用的时候，需要在bfd的
dubbo.consumer.xml中配置，因为tsp的jar包提供服务给你调用，你作为消费方。同理在tsp模块的dubbo.provider.xml中也要做对应的配置。否则启动会bean启动失败。

至于如何配置，就不在赘述，网上资料很多，涉及到dubbo的知识，系统学习即可。

三、一些设计思想

---

1、我们把一些待处理事项抽象为EventBacklog模型
2、把一些收集信息抽象为InformationCollection模型
3、把业务和运营以及其他方来回沟通的过程抽象为ProgramPlan模型，即PP模型
4、我们把记录日志的抽象为field_change模型

这些都是高度抽象的、非常实用的设计思想，跟我们的架构师学习的，共勉之。

---

1、我们把一些待处理事项抽象为EventBacklog模型

user_id
resource_id
backlog_category
backlog_type
backlog_status
created_time
updated_time

其中backlogStatus包含以下几个状态：

CREATED
WAIT_TO_VIEW
WAIT_TO_HANDLE
CANCELED
FINISHED

实际效果是什么样子呢？类似红点的逻辑、待处理数字的逻辑都可以这么实现。

2、把一些收集信息抽象为InformationCollection模型

业务经常搞促销，或者以各种方式收集信息。收集信息只是阶段性的，这个时候用统一的方式处理。
模型如下：

user_id
type
information

抽象意义：某个人在某个类型上的各种信息
其中：infromation是个复杂的key:value对象。你需要什么信息，就定义什么即可。

3、把业务和运营以及其他方来回沟通的过程抽象为ProgramPlan模型，即PP模型。

owner_id
company_id
type
status
program
created_by
created_time
updated_by
updated_time
confirmed_by
confirmed_time
owner_confirmed_by
owner_confirmed_time

然后在来一个模型记录沟通过程

pp_id
program
new_program
confirmed
is_online
....

上面最核心的是program，这个存放的是每次沟通的内容，扔进去的是复杂对象:K-V形式。
status一般有以下几个状态：

INIT
CREATED
REQUEST_UPDATE
OWNER_CONFIRMED
PLAT_FORM_CONFIRMED
ONLINE
OFFLINE

这里的
OWNER_CONFIRMED
PLAT_FORM_CONFIRMED
用到了四眼原则，即同一人对自己的操作需要过“冷静期”或者在冷静期内由他方来confirm ，避免“大权独揽”，最大化减小失误。

整个沟通的record记录在了negotiation模型里，这样所有类似“乒乒乓乓”的过程都可以走这个模型。

同理，我们还可以抽离出一个个申请模型、邀请模型等等。

4、我们把记录日志的抽象为field_change模型

关键操作需要记录日志，那么把日志记录抽象出来

resource_id
change_field
old_value
new_value
created_by
created_time
operator_id

无论什么变更，都可以套用这个模型

四、《实现领域驱动设计》

这本书内容非常干货！
But，需要多看几遍

印象最深的几个地方是：
界限上下文
六边形架构
贫血
值对象
publish event
Command
DTO（
我们目前前端传入的参数就是用Command封装，返回给前端的用DTO，怎么返回给前端呢？通过Transformer把Entity转成DTO）

再啰嗦一句，这本书内容很干货！