核心領域模式 -Nick Tune
時間和資源是有限的,在開發軟體系統時,我們如何花費有限時間並利用有限資源解決最根本、最困難的挑戰?在我們可能要做的所有事情中,我們應該做什麼,我們應該投資多少質量和嚴格度?
對於軟體工程師來說,自然的趨勢是傾向於迎接最有趣的“技術”挑戰。儘管並非總是如此,但我可以從自己的親身經歷中確認。
但是,遵循領域驅動設計方法的開發人員會認為這其中存在平衡。一種稱為核心子域的概念,核心子域是系統中具有最高業務投資回報率的部分。
作為開發人員,我們應該尋找這種核心領域,以幫助我們的專注能產生最大的效果,而不是被技術上有趣但投資回報率低的功能所吸引。
核心域伴隨著支援子域和通用子域。支援子域是業務必需品,它們包含與該域相關的業務概念,但是投資回報率有限。通用域代表的是我們域中不唯一的概念,例如使用者身份,傳送電子郵件,付款等,我們應該考慮購買SaaS或使用開源而不是構建通用子域。
為了使這些概念更加清晰,結構化和量化,使它們更易於理解和應用,我一直在使用以下基本視覺化方法。
根據此定義,核心域是具有高度業務差異性機會的域領域。這代表了引人注目的ROI。另外,實現必須至少具有合理的複雜度(模型複雜度)。如果一個簡單的基於資料的表格(又名CRUD)解決方案就足夠了,那麼我們不應該浪費時間進行過度的設計。
使用這種視覺化,我們可以走得更遠,找到可以指導我們現在和將來的技術策略和軟體開發投資的模式。
決定性核心
當核心域極其複雜並提供最大的業務差異化潛力時,這是決定性的能力。具有決定性意義,因為無論哪個組織擁有這項權利,都有可能成為市場領導者。高度的複雜性使得需要大筆投資才能取得勝利。
短期核心
當核心域具有較高的分化潛力而複雜性相對較低時,它可能是短期核心。由於複雜性低,這不是防禦性的優勢,競爭將在相對較短的時間內趕上。
隱藏的核心
潛在的反模式值得警惕。如果上下文的複雜性很低,並且是一個簡單的資料表單的CRUD系統,那麼它就不是我們需要創新的核心領域。
但是,如果這種能力代表著與企業不同的東西,我們應該提防:複雜性如果仍由員工手動處理,軟體系統只是在更換紙張。
在這種情況下,企業應該問:“我們可以在這裡利用技術的潛力嗎?我們可以採用手動流程,讓計算機完成人們當前正在做的所有艱苦工作嗎?”。
資料表單賭注式的核心
任何創新的自然生命週期是,隨著時間的流逝,它變成了賭注,不再是能夠與眾不同的創新,而是仍然需要的東西。
還記得第一波商店和餐館何時開始非接觸式付款嗎?奇妙,便捷的原因影響了您選擇購物或用餐的地方。而現在,我們期望無處不在的支付方式。
商品化的核心
曾經是核心域的領域可以變成一種通用功能,任何公司都可以輕鬆地將其用作SaaS產品或開源工具。
商品化核心的一個示例是搜尋引擎。如果您的產品依靠高階搜尋功能來與競爭對手區分開來,那麼像Elasticsearch這樣的最先進的開源軟體和SaaS搜尋引擎的到來將破壞您的優勢,從而為任何潛在的競爭對手提供與您競爭的能力。
黑天鵝核心
有時,完全出乎意料的事情發生了,表面上的商品可能成為核心領域。在這裡想到了Slack的故事。
Slack開始成為影片遊戲市場中一家公司的內部聊天系統。當影片遊戲未能產生收入時,公司決定將其聊天系統轉變為產品。Slack現在的價值為130億美元。
IRC已經是一個既定的聊天標準,可以達到目的。似乎沒有什麼分化潛力。沒有人看到機會,甚至沒有看到機會,他們都在使用該產品。
大賭注核心/破壞性核心
對於許多計劃而言,業務差異化的潛在水平是未知的。在產品交付並獲得市場反饋之前,沒人能確定。
由於潛力如此之大,可能會破壞整個行業,因此這種能力可能是一個大賭注,因為組織必須注入大量資源,並使其成為主要關注點,因為相信ROI可能是巨大的。
可疑的支援子域
如果有界的上下文非常複雜卻僅能提供支援功能,則應提出嚴肅的問題。業務差異相對較小的事物為何需要如此高的投資來管理複雜性?
一個完全正確的原因是意外的複雜性太高了:也許是從舊系統遷移到新系統。應該制定降低複雜性的清晰計劃和時間表,以確保將浪費的精力重新分配給具有更高分化潛力的功能。
進入下一個層次
我發現評估有界上下文來區分業務差異和複雜性是一個非常實際和可接近的起點。對於不瞭解其架構如何與業務模型聯絡的團隊,我發現這種技術方法在使開發人員能夠更多地思考業務觀點,尤其是隨著時間的推移而發展方面非常有用。
要了解功能為何會隨著時間的推移在差異化和複雜性方面發展,我強烈建議您研究Wardley Mapping和Cynefin框架。
瞭解不同型別的複雜性也很重要-複雜性與偶然性以及偶然性複雜性的各個子類別。
相關:
相關文章
- 上下文對映關係中如何解耦特定和通用的領域? - Nick Tune解耦
- 領域驅動設計戰術模式--領域事件模式事件
- DDD劃分領域、子域,核心域,支撐域的目的
- 領域驅動設計戰術模式--領域服務模式
- 領域驅動設計核心概念
- 可以促進微服務設計的DDD事件風暴建模技巧 - Nick Tune微服務事件
- 領域邏輯的組織模式模式
- 位元組面試:領域、子域、核心域、通用域和支撐域怎麼劃分?面試
- 領域模型的核心本質是什麼?模型
- 領域驅動系列:三種領域邏輯組織模式的本質模式
- 戲說領域驅動設計(十五)——核心元素
- 戲說領域驅動設計(十三)——核心架構架構
- 《UML和模式應用》與《領域驅動設計.軟體核心複雜性應對之道》模式
- 領域驅動設計戰術模式--值物件模式物件
- 領域驅動設計--戰術模式簡介模式
- DDD-領域物件與領域服務物件
- DDD領域驅動設計:領域事件事件
- 戲說領域驅動設計(九)——架構模式架構模式
- DAO模式是不是就是領域建模中的倉儲?模式
- 資料治理九大核心領域,以銀行業為例行業
- Linux作業系統成功涉足核心應用領域(轉)Linux作業系統
- 流批一體在 AI 核心電商領域的探索與實踐AI
- 戲說領域驅動設計(廿五)——領域事件事件
- CloudNotes之領域建模篇:領域模型簡介Cloud模型
- 讀書系列-《解構領域驅動》-領域概念
- 在 VUCA 世界中培養你的領導力敏捷性 - Nick Horney敏捷
- 領域服務和領域事件如何取捨?或共存?事件
- 分散式系統中的解耦模式:領域查詢 - mathiasverraes分散式解耦模式
- 請教各位:CTI IVR領域該應用那些設計模式?VR設計模式
- 使用DDD聚合發現隱藏的業務規則的案例分析:資料庫事務的業務實現 - Nick Tune資料庫
- ABP框架領域層框架
- 淺談領域模型模型
- 「完結」 12篇文章帶你完全進入NLP領域,掌握核心技術
- 領域驅動設計DDD和CQRS架構模式落地實踐架構模式
- Android官方架構元件LiveData: 觀察者模式領域二三事Android架構元件LiveData模式
- 《實現領域驅動設計》筆記——領域、子域和限界上下文筆記
- 資訊領域核心技術扼在美國手裡,我們該何去何從?
- 中興GoldenDB秦延濤:國產資料庫進入金融級核心應用領域Go資料庫