程式，隨便紀錄

Spring Security  分成 認證跟授權 Spring Security在進行安全驗證時收到輸入請求中的使用者名稱(username)，然後呼叫UserDetailsService.loadUserByUsername(String username)並傳入username去「記錄使用者資訊的地方」尋找對應的使用者，然後將找到的使用者資訊以UserDetails的形式回傳給AuthenticationProvider（的實作）進行接下來的驗證。 https://chikuwa-tech-study.blogspot.com/2021/06/spring-boot-security-authentication-and-authorization.html https://matthung0807.blogspot.com/2019/09/spring-security-userdetailsservice.html https://www.toptal.com/spring/spring-security-tutorial https://x8795278.blogspot.com/2019/12/spring-boot-spring-security-rest-api.html

 CAP理論 4+1 架构视图模型 事件溯源 事件驅動 pubsub 發布訂閱 觀察者模式 XA / DTM 单点登录 gprc vs mqtt LWM2M/CoAP SOA VS SAAS 二階段提交 分布式授權 CQS是 function等級的設計 CQRS是 module等級的設計 魯棒圖

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 應該要有完整職責