ddd-crew/core-domain-charts:幫助查詢DDD核心子域的複雜性分析工具集
核心子域圖幫助您視覺化架構中每個(子)域或業務能力的戰略重要性,從而使您能夠做出與業務模型一致的架構決策。
這種技術的真正力量在於它引發的對話,尤其是跨學科的對話。複雜性是工程師可以衡量的東西,而業務差異化是由產品經理或業務利益相關者提供的。
衡量複雜性的重要性
首先,衡量你的領域的複雜性和差異化是很困難的,而且通常是相當主觀的。戰略是對未來的賭注,因此您永遠無法確定某件事最終會變得多麼複雜或差異化。但是,討論和視覺化您對每個領域的複雜性和差異性的信念仍然有很多價值。
以下線索可以幫助評估每個領域的複雜性和差異性。
- 為領域設計概念模型並將其構建(和維護)為軟體有多困難?(基本領域複雜性)
- 當前的技術解決方案是否比提供當前功能所需的複雜?(意外的技術複雜性)
- 軟體外部是否發生了複雜的流程、計算和決策?(操作複雜性)
- 一個新進入市場的人要達到或超過其能力有多難?
- 現有競爭對手要達到或超過其能力有多難?
- 目前有多少優勢來自(子)域(收入、品牌、參與度)?
- (子)領域(收入、品牌、參與度)可能帶來多少優勢?
- 如果該領域發生重大或反覆出現的故障,會對品牌造成什麼損害?
- 它屬於哪個cynefin 哪個域?
複雜性可以以不同的形式表現出來。以下是揭示每個(子)域的基本域複雜性、偶然技術複雜性和操作複雜性的一些線索:
- 發現潛在的新價值有多難?
- 設計創造價值的規則、邏輯和工作流程有多難?
- 系統需要以什麼規模執行?(即使規則更簡單,規模也會增加很多複雜性)
- 是否需要非常高水平的差異化/複雜性來取代現有的市場領導者或在飽和市場中?
- 是否需要難以獲得且昂貴的專業知識/人才(發現和/或交付價值)?
- 新人需要多長時間才能提高效率並提高效率?
幾種使用方式:
核心域圖有多種使用方式,但重要的是不要試圖在單個圖表中視覺化所有可能的資訊。以下是多個版本,顯示了可供選擇的不同型別的資訊。
- (子)領域/有界上下文組合
這是最簡單的味道。只需在圖表上繪製每個(子)域或有界上下文,以獲得它們之間的相對順序感。
- 具有團隊拓撲的上下文對映
您可以使用有界上下文和正在使用的團隊拓撲互動模式型別之間的依賴關係來擴充您的核心域圖表。
- 架構遷移
稍微調整一下 y 軸標籤,就可以使用核心域圖表來規劃從當前架構遷移到目標架構的順序。
相關文章
- 解決DDD核心的複雜性
- 複雜查詢—子查詢
- SQL 複雜查詢SQL
- SQL複雜查詢SQL
- JPA的多表複雜查詢
- es的複雜查詢測試,使用jest的dsl工具寫查詢語句
- oracle表複雜查詢Oracle
- Oracle複雜查詢(三)Oracle
- Solr複雜查詢一:函式查詢Solr函式
- Laravel使用MongoDB複雜的查詢LaravelMongoDB
- 複雜查詢語句的使用
- 查詢與排序01,線性查詢,時間複雜度,演算法排序時間複雜度演算法
- Linux查詢檢視幫助命令Linux
- SQL學習(三) 複雜查詢SQL
- SQL複雜查詢多表連線SQL
- 演算法複雜性分析演算法
- SQL 複雜的求值計算---師哥師姐給個幫助SQL
- [java程式碼]業務邏輯查詢幫助類Java
- linux中查詢find命令的複雜用法Linux
- 如何完成複雜查詢的動態構建?
- 探討一個比較複雜的查詢
- Laravel Query Builder 複雜查詢案例:子查詢實現分割槽查詢 partition byLaravelUI
- 微服務複雜查詢之快取策略微服務快取
- 老司機使用 Redis 快取複雜查詢Redis快取
- Vert.x Future 解決複雜查詢
- Hibernate對於複雜查詢好用嗎?
- 複雜查詢還是直接寫sql吧SQL
- Spring JPA聯表情況下的複雜查詢Spring
- 查詢(3)--雜湊表(雜湊查詢)
- ddd-crew/ddd-starter-modelling-process:DDD設計入門建模流程
- DDD函式程式設計案例:戰勝軟體開發的複雜性! 戰勝方式本身有點複雜哦!函式程式設計
- 寫一個“特殊”的查詢構造器 – (四、條件查詢:複雜條件)
- 使用 Redis 解決“樹”形資料的複雜查詢Redis
- 包含複雜查詢的快速重新整理的物化檢視
- 複雜性系統的戰略分析要點 -Dave
- Mysql 日期格式化 複雜日期區間查詢MySql
- Oracle查詢轉換(二)複雜檢視合併Oracle
- 複雜度分析的套路及常見的複雜度複雜度