總摘要: 領域建模
2018-01-22
- 摘要: 領域建模.
1. 領域建模中，狀態(tài)的轉(zhuǎn)變不是直接更改原先記錄中的狀態(tài)，而是一件一件的事件都記錄下來壶冒，然后根據(jù)這些事件計算出當前的狀態(tài)，這么理解對么？ [北京-二兩豆腐]
北京-喜<-> 19:35:40
如果你依賴記錄事件破托，沒什么關系。 但是原紀錄就不需要有狀態(tài)了
北京-二兩豆腐<-> 19:36:01
但是這會給查詢帶來很大的復雜性
北京-喜<-> 19:36:07
如果原紀錄有狀態(tài)歧蒋，那么這個狀態(tài)就是唯一正確解, 記錄只能作為追溯, 這是2種思路
北京-二兩豆腐<-> 19:36:43
如果不需要追溯土砂，是不是就沒必要采用這種設計[對], 那就是還是基于狀態(tài)的
北京-喜<-> 19:37:28
換句話說, 為什么要算呢。因為結果從現(xiàn)在這個時刻去看谜洽，是確定的
北京-二兩豆腐<-> 19:37:42
一條記錄萝映，根據(jù)事件更新狀態(tài)字段
杭州－東子(-) 19:38:08
數(shù)據(jù)庫進行修改操作是不是就是保留原來的記錄，新增了一條修改后的數(shù)據(jù)阐虚，然后過一段時間刪除之前的舊的數(shù)據(jù)靶虮邸？
北京-喜<-> 19:38:16
不是去改過去的記錄, 而是記錄最新的結果
北京-二兩豆腐<-> 19:39:18
嗯嗯实束，對奥秆，上面說給架構上帶來很大的好處，還會有什么好處呢
北京-喜<-> 19:39:43
沒什么好處, 我猜測作者是從時間序列上有些體會咸灿，推導出的結論
北京-二兩豆腐<-> 19:40:45
哈哈构订。好吧，不過領域建模上也確實是這么建議的
北京-喜<-> 19:40:53
更新數(shù)據(jù)并不是改過去的結果析显，而是記錄最新的信息現(xiàn)狀, 非最新的記錄鲫咽，都被丟棄, 這也是一個可選思路。 但是他認為是更改過去的結果, 領域設計上應該沒有這種建議谷异，領域建姆质基本沒說具體到這么細化的問題
北京-二兩豆腐<-> 19:42:43
說的是基于事件建模，不要基于狀態(tài)
北京-喜<-> 19:43:29
我認為都可以的, 主要是尺度的拿捏, 事件本身也有膨脹問題, 狀態(tài) 也有大狀態(tài)歹嘹、小狀態(tài), 大小狀態(tài) 都可以是事件
北京-二兩豆腐<-> 19:44:32
那就行箩绍，本來想在我這邊的一個需求上采用這種設計試試，但是感覺沒什么好處尺上，反而增加了復雜性
北京-喜<-> 19:44:55
事件最大的問題 是流程的可視問題, 編程上解耦很好, 但是鏈路和協(xié)作關系材蛛，人比較難理解和追蹤, 狀態(tài)機 相對清晰一些
北京-二兩豆腐<-> 19:46:04
對，通過分解事件怎抛，eventstroming 卑吭，這樣能清晰的劃分系統(tǒng)邊界, 對于復雜系統(tǒng)，做微服務化拆分比較有好處
北京-喜<-> 19:46:35
這個eventstroming 不夠, 表達不出來協(xié)作關系
北京-二兩豆腐<-> 19:47:56
還要用到四色建模
北京-喜<-> 19:48:27
只要理解四色模型就行了, 事件驅(qū)動马绝，當需要了解業(yè)務全貌 或者 故障排障的時候豆赏，特別困難,
北京-二兩豆腐<-> 19:49:20
謝謝喜神，通過討論我決定手中的這種需求不采用這種設計方式了，還是繼續(xù)基于狀態(tài), 對于業(yè)務領域特別復雜的時候比較適用, 開發(fā)人員和業(yè)務專家阻抗比較高
北京-喜<-> 19:50:47
我比較傾向任務驅(qū)動, 任務有分類, 越是復雜的事務掷邦，事件驅(qū)動越麻煩, 從已落地的代碼上白胀，沒有人能說清楚業(yè)務鏈路, 因為全是解耦的, 需要額外記錄、或者依靠技術組件的trace抚岗、或者一些視圖啥的.
北京-石板路上的少年(-) 19:55:21
@ffud 從已落地的代碼上或杠，沒有人能說清楚業(yè)務鏈路, 這個不至于吧!
北京-喜<-> 19:55:46
就是說你發(fā)出去的事件，如果是跨應用的, 從自己的編碼上 是不知道消費者是誰的, 自然業(yè)務到這里就停止的宣蔚，從代碼沒法繼續(xù)推斷下去了, 我們訂單系統(tǒng)里面很多自消費的向抢、跨應用的, 所以需要額外的文字記錄
蘇州-一樹梨花啊(-) 19:56:19
但每個消費者的業(yè)務還是清楚的, 消費者自己的業(yè)務
北京-喜<-> 19:56:52
我不相信你查MQ topic能查清楚, 這個樹狀、圖狀的依賴關系
福州-風火(-) 19:55:30
喜神能說說任務驅(qū)動嗎件已？
北京-喜<-> 19:58:04
和日常的工作基本一致, 比如你的老板給你下發(fā)一個任務笋额， 有時候需要應答篷扩，有時候不需要
福州-風火(-) 19:59:03
從這個角度，感覺和單一事件類似鉴未？
北京-喜<-> 19:59:03
你完成一個任務，有時候需要周知老板铜秆，有時候需要周知一堆關聯(lián)人淹真，有時候誰也不需要周知
福州-風火(-) 19:59:13
我好像沒有理解
北京-喜<-> 19:59:31
所以任務有幾個分類, 無非通知老板的時候，可以是異步通知
福州-風火(-) 19:59:49
那任務人本身是否需要知曉周知人连茧？
北京-喜<-> 19:59:57
這一步 就是現(xiàn)在在用的事件驅(qū)動，僅僅異步就夠了, 各個關聯(lián)人客扎，假如你不知道，比如你在群里喊下罚斗，什么事情已經(jīng)done
福州-風火(-) 20:00:35
那不同于事件驅(qū)動的地方是徙鱼？
北京-喜<-> 20:00:35
就是現(xiàn)在的MQ廣播模式, 事件驅(qū)動是任務驅(qū)動的一個子集
福州-風火(-) 20:01:39
我查查資料去，謝謝喜神
北京-喜<-> 20:01:53
好像沒有資料
成都-并發(fā)(-) 20:02:16
事件驅(qū)動是來一個事件针姿，用一個線程去跑
福州-風火(-) 20:02:58
不太明白任務驅(qū)動的定義
北京-喜<-> 20:03:50
我們?nèi)粘９ぷ髦校瑓f(xié)作的方式, 和計算機系統(tǒng)之間的協(xié)作绞绒，是一致的, 事件驅(qū)動榕暇，只表達了其中的一個部分
福州-風火(-) 20:04:32
那和消息驅(qū)動饲趋，感覺又混了
北京-喜<-> 20:05:03
消息驅(qū)動也一樣 ,大部分事情撤蟆，基本上收到的時候，已經(jīng)訂好了應答方式,事件驅(qū)動和消息驅(qū)動家肯，都沒有定義這個關系, 比如 老板給你1個任務盟猖。 你完成之后，需要告訴老板反镇， 也需要告訴PM娘汞、銷售、QA等, 通知給老板的方式你弦，和通知PM、銷售尸昧、QA的方式旷偿，其實不一樣的
福州-風火(-) 20:06:58
消息和事件都只管發(fā)出去。不管回來萍程，是這個意思吧
北京-喜<-> 20:07:33
啥都沒管，所以看起來啥場景都適合, 但是當精細化追溯鏈路和數(shù)據(jù)關系的時候磁浇，追蹤不出來
廣州-小護士<-> 19:54:22
對于沒有上下文關系的行為可以抽象為事件朽褪？有上下文關系且鏈路很深的要抽象為pipeline？
福州-風火(-) 20:07:40
pipe應該是組合事件和編排相關吧缔赠。和抽象無關嗤堰？
廣州-小護士<-> 20:08:00
我就是說，你要查鏈路的，就用pipeline, 就像jenkinFile那種寫法
北京-喜<-> 20:09:01
不是同步編碼實現(xiàn)pipeline, 而且任務的數(shù)據(jù)結構上 自描述的
福州-風火(-) 20:09:50
我有點理解了戈抄。每個任務自描述后专，方便追蹤
北京-喜<-> 20:09:54
只看這個數(shù)據(jù)結構，就知道各個環(huán)節(jié)戚哎，向上和向下數(shù)據(jù)流是什么樣的
福州-風火(-) 20:10:05
能講講落地的方式嗎？
北京-喜<-> 20:10:21
具體的交互可以是command丈冬、事件
福州-風火(-) 20:11:24
那任務自描述使用何種方式達成甘畅？
北京-喜<-> 20:11:51
這個需要自己寫框架, 首先各個服務是得能表達的, 這個方案比較重
福州-風火(-) 20:12:08
謝謝，受教了粒梦。理念理解了荸实，落地不太容易.
北京-喜<-> 20:13:05
整體和建模思路一致，模型驅(qū)動, 數(shù)據(jù)鏈路准给、應用關系，也是可以建模的. 事件驅(qū)動 我們也在用, 搞了十幾個事件祖灰，后來不敢繼續(xù)搞了, 沒人能說清楚數(shù)據(jù)流向了
長沙-艾爾(-) 20:14:00
那消息驅(qū)動是什么畔规。。三妈。跟事件驅(qū)動是什么關系莫绣。。对室。
福州-風火(-) 20:14:30
事件驅(qū)動可以認為是消息驅(qū)動的特異化, 計算機協(xié)作建立在消息基礎上
成都-梅小西(-) 20:17:02
基于event編程和基于reactor編程咖祭，有什么區(qū)別
北京-喜<-> 20:17:29
reactor 多了一個處理器模型
廣州-小護士<-> 20:17:38
reactor就是pipeline的味道
北京-喜<-> 20:17:52
整體全部是事件驅(qū)動么翰，不管同步還是異步, 通常我們使用的事件驅(qū)動纠吴，一般是指的 異步事件
成都-梅小西(-) 20:18:09
java9原生支持reactor了
北京-喜<-> 20:18:32
不是說不是好東西, 就是太靈活了, 業(yè)務鏈路追溯很困難, 需要拿持久化的handler追蹤, 以前的編程習慣是，用代碼的調(diào)用關系反應業(yè)務流程和數(shù)據(jù)走向, 現(xiàn)在可以轉(zhuǎn)到數(shù)據(jù)結構上戴已，上次分享的時候EF框架有一部分這個意思
長沙-艾爾(-) 20:20:26
用了這樣那樣的驅(qū)動锅减，就掩蓋了調(diào)用鏈怔匣。。每瞒。
北京-喜<-> 20:21:08
系統(tǒng)最外層接收數(shù)據(jù)和命令之后，對于整體的處理節(jié)點代芜，就確定了
北京-張文(-) 20:21:21
通過日志追蹤浓利？
北京-喜<-> 20:21:24
有個整體的數(shù)據(jù)結構表達所有的處理節(jié)點, 日志是補丁，依賴程序員的編程素質(zhì), 每次調(diào)用走的只是一條路, 整體思路就是所有的信息都是可以建模的, 即便是各個處理過程. 你寫的Service贷掖，都是可以被抽象的JVM server, 也可以抽象個模型來表達, 每個task/data 需要哪些server 協(xié)作苹威，也是可以描述的, 資源也是可以抽象的.
