區(qū)分問題和解決方案是領(lǐng)域驅(qū)動設(shè)計(jì)的秘訣
每個人都知道，在制作軟件時，業(yè)務(wù)人員是相關(guān)的。在實(shí)踐中不太確定的是，業(yè)務(wù)人員在軟件構(gòu)建的每個步驟中都至關(guān)重要，而不僅僅是在概述高級需求方面。
為什么？因?yàn)闃I(yè)務(wù)人員是問題的代表，也是解決問題的價(jià)值的代表。他們進(jìn)入問題空間。
軟件開發(fā)人員進(jìn)入解決方案空間，這是解決問題的成本。
軟件開發(fā)作為一門學(xué)科，專注于解決方案，但軟件開發(fā)人員只有在明確定義解決方案的業(yè)務(wù)領(lǐng)域時才能控制解決方案。
制定戰(zhàn)略需要領(lǐng)域?qū)＜?。將一些?jīng)驗(yàn)豐富的業(yè)務(wù)分析師甚至軟件開發(fā)人員視為領(lǐng)域?qū)＜沂且粋€容易犯的錯誤。
領(lǐng)域?qū)＜壹炔皇鞘占枨蟮姆治鰩煟膊皇窃O(shè)計(jì)系統(tǒng)的工程師。領(lǐng)域?qū)＜掖順I(yè)務(wù)。他們是首先發(fā)現(xiàn)業(yè)務(wù)問題的人，也是所有業(yè)務(wù)知識的來源。
領(lǐng)域?qū)＜姨峁I(yè)務(wù)語言。我將用整篇文章來介紹無處不在的語言；目前，最重要的是讓業(yè)務(wù)語言成為設(shè)計(jì)戰(zhàn)略的基礎(chǔ)。
戰(zhàn)術(shù)設(shè)計(jì)是 DDD 的第二階段。這是解決方案的重點(diǎn)所在，請記住，解決方案是解決問題的成本。
解決方案是有代價(jià)的。就解決的問題帶來的價(jià)值而言，解決方案是值得付出的成本。
區(qū)分問題和解決方案的 DDD 配方提供了最相關(guān)的成分：單詞。在這種語言中，“戰(zhàn)略”和“策略”具有深刻的含義，不再是無意義演示的流行語。
要點(diǎn)：問題帶來了價(jià)值，而解決方案就是解決該問題的成本；這就是為什么讓它們與眾不同是至關(guān)重要的。
2、如何實(shí)現(xiàn)多限界上下文的集成？
我們的目標(biāo)是能夠建立一種明確的方式或語言，用于專家和開發(fā)人員之間的交流。這意味著所有在代碼中表示或沒有表示的概念，例如類和進(jìn)程，都不應(yīng)該被任意命名或以開發(fā)人員為中心的觀點(diǎn)，而是作為關(guān)于您的軟件解決方案如何試圖解決給定問題的聚合討論的結(jié)果。
收斂到正確的語言是強(qiáng)大的，因?yàn)樗梢詭椭鷮㈦[式定義顯式化，這總是一件好事。想象一下，您發(fā)現(xiàn)它實(shí)際上是一個目的地地址，而不是調(diào)用“Shipping Information”。
讓我們有一些邊界感
在討論有界的界限上下文（Bounded Contexts，BC）的概念時，Eric Evans指出我們應(yīng)該“顯式定義模型應(yīng)用的上下文。在團(tuán)隊(duì)組織、應(yīng)用程序特定部分的使用以及代碼庫和數(shù)據(jù)庫模式等物理表現(xiàn)形式方面顯式地設(shè)置邊界。保持模型在這些界限內(nèi)嚴(yán)格一致，但不要被外部問題分散注意力或混淆。
這句話暴露了一個事實(shí)，即我們的模型，以及最終定義它們的語言，都有一個限度。它還強(qiáng)化了有一些 '在 '極限之外的東西，我們不應(yīng)該被其 '分心'。雖然討論如何定義這些界限不屬于本文的范圍，但我想把重點(diǎn)放在限制的存在上，如圖1所示。
限界上下文之間可能有也可能沒有關(guān)系
從一個限界上下文到另一個模型可以具有相同的名稱但不同的定義
從一個限界上下文到另一個模型可以有不同的名稱，但具有一些或所有共同特征
對于它們之間沒有任何關(guān)系的限界上下文，沒有什么好說的，只是重申如果你在兩者中找到相同的模型名稱就可以了。假設(shè)這是仔細(xì)決定/迭代的結(jié)果。
另一方面，對于共享關(guān)系的限界上下文，讓我們看一下上下文映射，它提供有關(guān)它們的關(guān)系如何影響它們的模型和語言的附加信息。
上游/下游
反腐敗層
..點(diǎn)擊原文鏈接
3、什么是以領(lǐng)域?yàn)橹行牡募軜?gòu)及其誤解？
以領(lǐng)域?yàn)橹行牡?/span>架構(gòu)（洋蔥、干凈、六角形……）將基礎(chǔ)架構(gòu)分為驅(qū)動端（由主適配器組成）和從動端（輔助適配器）。驅(qū)動端是應(yīng)用程序的入口點(diǎn)：通過主要參與者，它觸發(fā)應(yīng)用程序的域（即核心）。被驅(qū)動端表示依賴的外部機(jī)制，例如數(shù)據(jù)庫和第三方API。
支持以域?yàn)橹行牡捏w系結(jié)構(gòu)的最常用論據(jù)是輔助適配器（驅(qū)動端）的易替換性。例如：
在新項(xiàng)目中，您可以遵循基于選項(xiàng)的方法：從沒有數(shù)據(jù)庫的情況下開始（例如，通過存儲在內(nèi)存中或文件系統(tǒng)中）并將該決定推遲到最后負(fù)責(zé)的時刻（精益軟件開發(fā)中的一個關(guān)鍵概念）。
如果/當(dāng)時間到了（并防止供應(yīng)商鎖定）時，替換數(shù)據(jù)庫很容易。
依賴技術(shù)并不局限于數(shù)據(jù)庫。許多其他地方正在發(fā)生技術(shù)波動。例如，如果某些外部服務(wù)計(jì)劃從 GRPC 切換到 REST，則只有一個更改位置（適配器）。
一些測試策略依賴于輕松換出輔助適配器，例如使用內(nèi)存中實(shí)現(xiàn)代替真實(shí)的數(shù)據(jù)庫存儲庫或使用偽造的 API 代替外部 API。這使得測試更快、更穩(wěn)定，并允許單獨(dú)測試域（盡管默認(rèn)情況下我更喜歡垂直測試）。
將焦點(diǎn)轉(zhuǎn)移到領(lǐng)域
干凈的六邊形架構(gòu)是與領(lǐng)域驅(qū)動設(shè)計(jì)密切相關(guān)的架構(gòu)模式。因此，應(yīng)用程序應(yīng)該以領(lǐng)域?yàn)橹行暮皖I(lǐng)域驅(qū)動，而不是由數(shù)據(jù)或數(shù)據(jù)庫驅(qū)動，這是三層架構(gòu)中的典型趨勢?；A(chǔ)架構(gòu)決策（例如，Web API 定義和數(shù)據(jù)庫模式）應(yīng)該作為域需求的結(jié)果發(fā)生。域不應(yīng)該知道相應(yīng)適配器中隔離的周圍基礎(chǔ)設(shè)施。
“我們中的許多開發(fā)人員長期以來一直使用分層模型，以至于它已成為第二天性，我們認(rèn)為圍繞數(shù)據(jù)庫規(guī)劃應(yīng)用程序是世界上最正常的事情。首先規(guī)劃和開發(fā)應(yīng)用程序的業(yè)務(wù)方面不是更有意義嗎？”
易于替換有助于將重點(diǎn)從技術(shù)轉(zhuǎn)移到應(yīng)用程序的目標(biāo)，并將技術(shù)方面視為細(xì)節(jié)。它迫使開發(fā)人員將軟件視為一組行為，而不是數(shù)據(jù)庫編輯器或 CRUD 提供程序。代碼庫和面向公眾的 API 的設(shè)計(jì)應(yīng)該圍繞用例（以用戶為中心）而不是 CRUD（以技術(shù)為中心）。
隔離
曾經(jīng)，我不得不維護(hù)一個代碼庫，其中 SQL 查詢遍布各處；這既麻煩又可怕。輔助適配器將與數(shù)據(jù)相關(guān)的決策隔離在一個單一的內(nèi)聚位置。例如，ORM 對象和操作應(yīng)該只存在于存儲庫中。一個更簡單的例子：如果 JSON 屬性發(fā)生變化，則爆炸半徑被限制在單個文件中。
當(dāng)我閱讀涉及技術(shù)的代碼時，我不想閱讀業(yè)務(wù)代碼，反之亦然（單層抽象）。業(yè)務(wù)領(lǐng)域規(guī)則太重要了，不能與技術(shù)細(xì)節(jié)混在一起。想象一下在更改重要業(yè)務(wù)規(guī)則時處理數(shù)據(jù)庫異常、網(wǎng)絡(luò)錯誤、緩存、UI 模板和重試。
停止考慮干凈的六邊形架構(gòu)，努力以領(lǐng)域?yàn)橹行摹?/span>簡單地將領(lǐng)域與技術(shù)分開是唯一在很長一段時間內(nèi)都很重要的原則。此外，請確保域使用通用語言UL，這意味著它的代碼（例如，變量、函數(shù)、類）遵守應(yīng)用程序域中商定的現(xiàn)實(shí)世界術(shù)語。這在代碼自文檔和支持團(tuán)隊(duì)溝通方面也起著關(guān)鍵作用。作為后續(xù)階段，它會為值對象、實(shí)體、用例和適配器建模。沒有必要進(jìn)一步復(fù)雜化；這種精簡的架構(gòu)涵蓋了大多數(shù)情況。當(dāng)您權(quán)衡收益時，付出的努力是最小的。
聯(lián)系客服
