七月的成长
七月过得挺好,再也没有频繁的短信了,感觉万籁俱寂,心情无比舒畅。
六七月技术有哪些进步呢?
这些进步主要集中在运用上:
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)
再啰嗦一句,这本书内容很干货!