总摘要: 领域建模
2018-01-22
- 摘要: 领域建模.
1. 领域建模中，状态的转变不是直接更改原先记录中的状态，而是一件一件的事件都记录下来，然后根据这些事件计算出当前的状态，这么理解对么？ [北京-二两豆腐]
北京-喜<-> 19:35:40
如果你依赖记录事件，没什么关系。 但是原纪录就不需要有状态了
北京-二两豆腐<-> 19:36:01
但是这会给查询带来很大的复杂性
北京-喜<-> 19:36:07
如果原纪录有状态，那么这个状态就是唯一正确解, 记录只能作为追溯, 这是2种思路
北京-二两豆腐<-> 19:36:43
如果不需要追溯，是不是就没必要采用这种设计[对], 那就是还是基于状态的
北京-喜<-> 19:37:28
换句话说, 为什么要算呢。因为结果从现在这个时刻去看，是确定的
北京-二两豆腐<-> 19:37:42
一条记录，根据事件更新状态字段
杭州－东子(-) 19:38:08
数据库进行修改操作是不是就是保留原来的记录，新增了一条修改后的数据，然后过一段时间删除之前的旧的数据啊？
北京-喜<-> 19:38:16
不是去改过去的记录, 而是记录最新的结果
北京-二两豆腐<-> 19:39:18
嗯嗯，对，上面说给架构上带来很大的好处，还会有什么好处呢
北京-喜<-> 19:39:43
没什么好处, 我猜测作者是从时间序列上有些体会，推导出的结论
北京-二两豆腐<-> 19:40:45
哈哈。好吧，不过领域建模上也确实是这么建议的
北京-喜<-> 19:40:53
更新数据并不是改过去的结果，而是记录最新的信息现状, 非最新的记录，都被丢弃, 这也是一个可选思路。 但是他认为是更改过去的结果, 领域设计上应该没有这种建议，领域建模基本没说具体到这么细化的问题
北京-二两豆腐<-> 19:42:43
说的是基于事件建模，不要基于状态
北京-喜<-> 19:43:29
我认为都可以的, 主要是尺度的拿捏, 事件本身也有膨胀问题, 状态 也有大状态、小状态, 大小状态 都可以是事件
北京-二两豆腐<-> 19:44:32
那就行，本来想在我这边的一个需求上采用这种设计试试，但是感觉没什么好处，反而增加了复杂性
北京-喜<-> 19:44:55
事件最大的问题 是流程的可视问题, 编程上解耦很好, 但是链路和协作关系，人比较难理解和追踪, 状态机 相对清晰一些
北京-二两豆腐<-> 19:46:04
对，通过分解事件，eventstroming ，这样能清晰的划分系统边界, 对于复杂系统，做微服务化拆分比较有好处
北京-喜<-> 19:46:35
这个eventstroming 不够, 表达不出来协作关系
北京-二两豆腐<-> 19:47:56
还要用到四色建模
北京-喜<-> 19:48:27
只要理解四色模型就行了, 事件驱动，当需要了解业务全貌 或者 故障排障的时候，特别困难,
北京-二两豆腐<-> 19:49:20
谢谢喜神，通过讨论我决定手中的这种需求不采用这种设计方式了，还是继续基于状态, 对于业务领域特别复杂的时候比较适用, 开发人员和业务专家阻抗比较高
北京-喜<-> 19:50:47
我比较倾向任务驱动, 任务有分类, 越是复杂的事务，事件驱动越麻烦, 从已落地的代码上，没有人能说清楚业务链路, 因为全是解耦的, 需要额外记录、或者依靠技术组件的trace、或者一些视图啥的.
北京-石板路上的少年(-) 19:55:21
@ffud 从已落地的代码上，没有人能说清楚业务链路, 这个不至于吧!
北京-喜<-> 19:55:46
就是说你发出去的事件，如果是跨应用的, 从自己的编码上 是不知道消费者是谁的, 自然业务到这里就停止的，从代码没法继续推断下去了, 我们订单系统里面很多自消费的、跨应用的, 所以需要额外的文字记录
苏州-一树梨花啊(-) 19:56:19
但每个消费者的业务还是清楚的, 消费者自己的业务
北京-喜<-> 19:56:52
我不相信你查MQ topic能查清楚, 这个树状、图状的依赖关系
福州-风火(-) 19:55:30
喜神能说说任务驱动吗？
北京-喜<-> 19:58:04
和日常的工作基本一致, 比如你的老板给你下发一个任务， 有时候需要应答，有时候不需要
福州-风火(-) 19:59:03
从这个角度，感觉和单一事件类似？
北京-喜<-> 19:59:03
你完成一个任务，有时候需要周知老板，有时候需要周知一堆关联人，有时候谁也不需要周知
福州-风火(-) 19:59:13
我好像没有理解
北京-喜<-> 19:59:31
所以任务有几个分类, 无非通知老板的时候，可以是异步通知
福州-风火(-) 19:59:49
那任务人本身是否需要知晓周知人？
北京-喜<-> 19:59:57
这一步 就是现在在用的事件驱动，仅仅异步就够了, 各个关联人，假如你不知道，比如你在群里喊下，什么事情已经done
福州-风火(-) 20:00:35
那不同于事件驱动的地方是？
北京-喜<-> 20:00:35
就是现在的MQ广播模式, 事件驱动是任务驱动的一个子集
福州-风火(-) 20:01:39
我查查资料去，谢谢喜神
北京-喜<-> 20:01:53
好像没有资料
成都-并发(-) 20:02:16
事件驱动是来一个事件，用一个线程去跑
福州-风火(-) 20:02:58
不太明白任务驱动的定义
北京-喜<-> 20:03:50
我们日常工作中，协作的方式, 和计算机系统之间的协作，是一致的, 事件驱动，只表达了其中的一个部分
福州-风火(-) 20:04:32
那和消息驱动，感觉又混了
北京-喜<-> 20:05:03
消息驱动也一样 ,大部分事情，基本上收到的时候，已经订好了应答方式,事件驱动和消息驱动，都没有定义这个关系, 比如 老板给你1个任务。 你完成之后，需要告诉老板， 也需要告诉PM、销售、QA等, 通知给老板的方式，和通知PM、销售、QA的方式，其实不一样的
福州-风火(-) 20:06:58
消息和事件都只管发出去。不管回来，是这个意思吧
北京-喜<-> 20:07:33
啥都没管，所以看起来啥场景都适合, 但是当精细化追溯链路和数据关系的时候，追踪不出来
广州-小护士<-> 19:54:22
对于没有上下文关系的行为可以抽象为事件？有上下文关系且链路很深的要抽象为pipeline？
福州-风火(-) 20:07:40
pipe应该是组合事件和编排相关吧。和抽象无关？
广州-小护士<-> 20:08:00
我就是说，你要查链路的，就用pipeline, 就像jenkinFile那种写法
北京-喜<-> 20:09:01
不是同步编码实现pipeline, 而且任务的数据结构上 自描述的
福州-风火(-) 20:09:50
我有点理解了。每个任务自描述，方便追踪
北京-喜<-> 20:09:54
只看这个数据结构，就知道各个环节，向上和向下数据流是什么样的
福州-风火(-) 20:10:05
能讲讲落地的方式吗？
北京-喜<-> 20:10:21
具体的交互可以是command、事件
福州-风火(-) 20:11:24
那任务自描述使用何种方式达成？
北京-喜<-> 20:11:51
这个需要自己写框架, 首先各个服务是得能表达的, 这个方案比较重
福州-风火(-) 20:12:08
谢谢，受教了。理念理解了，落地不太容易.
北京-喜<-> 20:13:05
整体和建模思路一致，模型驱动, 数据链路、应用关系，也是可以建模的. 事件驱动 我们也在用, 搞了十几个事件，后来不敢继续搞了, 没人能说清楚数据流向了
长沙-艾尔(-) 20:14:00
那消息驱动是什么。。。跟事件驱动是什么关系。。。
福州-风火(-) 20:14:30
事件驱动可以认为是消息驱动的特异化, 计算机协作建立在消息基础上
成都-梅小西(-) 20:17:02
基于event编程和基于reactor编程，有什么区别
北京-喜<-> 20:17:29
reactor 多了一个处理器模型
广州-小护士<-> 20:17:38
reactor就是pipeline的味道
北京-喜<-> 20:17:52
整体全部是事件驱动，不管同步还是异步, 通常我们使用的事件驱动，一般是指的 异步事件
成都-梅小西(-) 20:18:09
java9原生支持reactor了
北京-喜<-> 20:18:32
不是说不是好东西, 就是太灵活了, 业务链路追溯很困难, 需要拿持久化的handler追踪, 以前的编程习惯是，用代码的调用关系反应业务流程和数据走向, 现在可以转到数据结构上，上次分享的时候EF框架有一部分这个意思
长沙-艾尔(-) 20:20:26
用了这样那样的驱动，就掩盖了调用链。。。
北京-喜<-> 20:21:08
系统最外层接收数据和命令之后，对于整体的处理节点，就确定了
北京-张文(-) 20:21:21
通过日志追踪？
北京-喜<-> 20:21:24
有个整体的数据结构表达所有的处理节点, 日志是补丁，依赖程序员的编程素质, 每次调用走的只是一条路, 整体思路就是所有的信息都是可以建模的, 即便是各个处理过程. 你写的Service，都是可以被抽象的JVM server, 也可以抽象个模型来表达, 每个task/data 需要哪些server 协作，也是可以描述的, 资源也是可以抽象的.
