程式，隨便紀錄

https://www.runoob.com/docker/docker-hello-world.html https://yeasy.gitbook.io/docker_practice/image/dockerfile docker run docker exec  docker start docker stop docker ps docker logs docker exec -it docker rm -f  

 git:      sourcetree     gitlab flow restful api:     rate limit     冪等性     elk 監控     restful 規範 後端開發:     user story     use case      http://www.cjwind.idv.tw/OOAD-software-develop-cycle/ http://apframework.com/2020/03/22/ddd-color/ 項目： 適當的 transaction 和 try catch log 跟 email 當作 service 的一部分 用 interface 注入 該用啥資料庫就用啥 mysql 正規化 索引 使用 redis 快取結果 nosql 記錄其他內容 event、job queue、cronjob 架構 模組 上下文 切割程式碼  掌握所有系統跟資料庫的狀態 系統監控 資料庫監控 消息队列  = 异步、削峰、解耦 https://www.zhihu.com/people/aobingJava

誰使用domain service entity 能直接調用 repo 嗎 是否一定要聚合 區分bounded context 可以假設有多個部門或是多個開發者 參與主體 鲍勃大爷：先设计对象的行为，再设计数据库的表结构！ 先考慮參與者 为了识别某个概念是否属于某个限界上下文，问题就变成了： 是否都符合该主题的通用语言的要求？ 是否与该主题无关？ 是否更符合该主题的通用语言？ 是否是该主题的通用语言？ DDD 是設計方法 每個ＢＣ可以用ＭＶＣ架構也可以用clean architecture架構  最後都是回到ooad 所以去探討實作細節不如去看clean architecture  DDD還是著重在BC跟子域就好 跟對方公司部門 或是工程部門有關 https://www.jdon.com/53988 KISS 單一職責 DDD 戰略設計 + clean architecture 物件設計的判斷依據 行為 跟 資料 如何被使用 如果多增了一個類型要如何更改 如果依賴的東西變了 會怎麼被影響 如果物件改變了 依賴這個物件的class會如何被影響

只做一件事 只有一個改變的理由 開發程式的人必須對程式負責 不同職責的程式應該可以給不同的人開發而不互相影響 程式出錯只會找上一個人 而不是多個人 程式必須對使用他的人負責 職責改變並不影響使用者 程式必須對職責負責  職責改變只改變對他負責的程式 不改變使用者使用的情形 使用人 -> 程式 -> 職責 開發者 -> 程式 -> 職責 一個程式只負責一個職責 一個程式只給一個人開發 錯誤時只需找一個人負責 不會影響到其他程式 職責改變只會影響一個程式 只需改變一個程式 一個程式會給多個使用者使用 錯誤的點： 過多 class 是錯的 class 應該要有完整職責  single action 是錯的 class 應該要有完整職責 repository interface沒有 function 是錯的 interface 應該要有完整職責

 單元測試一定要可以直接運行 不依賴任何東西 一定要正規化資料庫 單一職責代表改需求只需改動一個地方 充血模型跟貧血模型沒有好壞 充血模型 比較優雅複雜 貧血模型 粗暴簡單 class 不要過多 會類爆炸 適度  單元測試逃不掉 single action是錯誤的 過多的class是錯誤的 repository的interface沒有function是錯誤的 組件間必須是單向關係 輔助組件必須指向核心組件 P65 步驟: 抓名詞 => user story => use case => 分析物件 模型 找出限界上下文 => 投射心智模型 => 封裝 單一職責 => 不管資料庫設計 => 每次開發都會得到新的特性 所以需要不斷調整模型和文件 => 重構  工作單元 最少驚訝原則 軟體接口如硬體接口 對象有狀態 行為 標識符 物件與物件的關聯 可以看成通道 有通道才能發送消息 對象責任代表維護知識跟可以執行的動作 正確使用 mysql Redis 事務跟 sharedlock 和 lockForUpdate