亚洲 欧美 自拍 动漫 免费 ,制服丝祙女教师在线播放,亚洲精品国产品国语原创,亚洲国产成人精品无码区在线网站

課程背景
領域驅動設計（Domai  Drive  Desig ，DDD）自誕生以來已有十幾年時間，它是針對復雜系統(tǒng)設計的一套軟件工程方法。由于面向對象分析與設計（OOA/OOD）的廣泛應用，并且與前期需求分析和后期系統(tǒng)開發(fā)有機銜接，在行業(yè)產生廣泛的影響，具有深遠的指導意義。但是，由于軟件的復雜度越來越龐雜和微服務的興起，領域驅動設計通過分而治之控制軟件規(guī)模，即一個大型復雜軟件都是由一個或多個微服務組成的，系統(tǒng)中的每個微服務可被獨立部署，微服務之間松耦合，且每個微服務只關注完成自己的任務并很好地完成任務。所以，領域驅動設計的思想和微服務架構風格的融合，從而指導復雜業(yè)務需求的軟件系統(tǒng)的設計、開發(fā)與維護，降低了系統(tǒng)業(yè)務分析的復雜度和技術實現的難度。
隨著業(yè)務領域的知識體系的龐大和復雜，業(yè)務處理邏輯或業(yè)務規(guī)則業(yè)隨之復雜、難于理解、難于清晰的表達等，并且其中夾雜的大量信息與軟件需要解決的問題無關。所以，在復雜系統(tǒng)設計方面存在如下主要問題：
  規(guī)模造就的復雜度：隨著需求的變化，系統(tǒng)規(guī)模會不斷擴張，軟件復雜度也不斷增長，除了需求功能本身的增加，還有功能之間的聯系變的牽一發(fā)而動全身，并且這個復雜度的增長往往是指數級的趨勢，這樣造成了軟件相關人員需要掌握大量信息，提升自己對業(yè)務需求和軟件的理解。
  結構造就的復雜度：為了滿足非功能性質量需求，例如高性能，高并發(fā)和高可靠性，在系統(tǒng)中引入緩存、并發(fā)處理、異步消息、海量數據的分布式存儲和高效分布式計算等讓系統(tǒng)在結構上變得復雜；為了保持系統(tǒng)有序，提高代碼可維護性，利用分層架構達到不同層次職責分離，設計的方案在架構上帶來了溝通成本的增加和管理上的困難；為了降低業(yè)務復雜度，拆分不同的子領域，往往因守不住領域的邊界而喪失了拆分的價值，系統(tǒng)結構會變的越來越混亂，會讓軟件的修改變得不確定。
  變化造就的復雜度：在設計軟件系統(tǒng)時，設計人員是無法完全預測系統(tǒng)的變化，一方面可能過于考慮變化的影響，過度的設計付出的成本就是浪費，另一方面，如果不對變化做任何的預測，又因不停的變化而不斷的付出較大研發(fā)成本。

課程收益
  面對大型復雜業(yè)務系統(tǒng)設計思想和設計理念的提升；
  傳統(tǒng)的軟件系統(tǒng)設計分析方法（OOA/OOD）的優(yōu)點和存在的問題；
  領域驅動設計的重點和難點，以及它解決問題的方法和過程；
  從領域問題到領域解決方案，全過程每個節(jié)點步驟的思想和方法；
  領域驅動設計中，上下文切分的思路，微服務關鍵問題的思考；
  領域驅動建模中，從分析建模→設計建模→實現建模的技術手段和思路。

參訓對象：研發(fā)總監(jiān)、研發(fā)經理/項目經理/技術經理/產品經理、系統(tǒng)工程師、軟件研發(fā)高級程序員、產品規(guī)劃專員

課程大綱
1 領域驅動設計--歷史背景
當前軟件系統(tǒng)開發(fā)面對的難題：系統(tǒng)需求的不確定性和易變性，以及系統(tǒng)的復雜性。
⑴ 當前存在的問題是什么？
系統(tǒng)的復雜性：問題的復雜性、實現的靈活性、行為描述的隨意性和管理開發(fā)過程的困難性；
⑵ 領域驅動設計的目標是什么？
軟件復雜性的應對之道：大型復雜業(yè)務系統(tǒng)分而治之的思想！
  規(guī)模--通過分而治之控制規(guī)模；
  結構--通過邊界保持清晰有序；
  變化--順應變化方向。
⑶ 領域驅動設計的方法是什么？
領域驅動設計的策略：大型復雜業(yè)務系統(tǒng)的領域建模方法體系！
  規(guī)模--以子領域、限界上下文對問題空間與解空間分而治之；
  結構--以分層架構隔離業(yè)務復雜度與技術復雜度，形成清晰的架構；
  變化--經領域抽象，以聚合為核心的領域建模，響應需求變化。

2 領域驅動設計--設計思想
講述領域驅動設計基本概念、主要內容、設計思想和設計過程，準確領悟領域驅動的戰(zhàn)略設計和戰(zhàn)術設計的內容及關系。
⑴ 領域驅動的概念、歷史根源和智慧；
⑵ 領域驅動的問題和步驟（六個問題和六個步驟）；
⑶ 領域模型的概念和主要思想；
⑷ 領域驅動設計的主要內容和過程；
⑸ 準確領悟領域驅動的戰(zhàn)略設計和戰(zhàn)術設計，以及戰(zhàn)略和戰(zhàn)術的關系。

3 領域驅動設計--全局分析
全局分析的目標就是確定問題空間，在統(tǒng)一語言的指導下，通過各種可視化手段，由領域專家與團隊一起完成對問題空間的探索，幫助領域驅動設計對準問題，輸出價值需求和業(yè)務需求。
價值需求既是目標系統(tǒng)的目標，也是對目標系統(tǒng)問題空間的界定和約束，它指導著業(yè)務需求分析。
業(yè)務需求由動態(tài)的業(yè)務流程和靜態(tài)的業(yè)務活動組成，二者的結合依靠業(yè)務場景按照時間點和業(yè)務目標對業(yè)務流程的切分。
通過運用商業(yè)模式畫布，可以獲得組成價值需求的利益相關者、系統(tǒng)愿景和系統(tǒng)范圍。
業(yè)務流程梳理可以幫助團隊對問題空間的各條業(yè)務線構成一個整體認識，弄清楚各種角色如何參與到一個完整的流程中，流程的時序性也可以避免識別業(yè)務活動時可能出現的缺失。
業(yè)務流程圖與服務藍圖以可視化的方式形象地呈現每一個提供了業(yè)務價值的業(yè)務流程。
業(yè)務活動是角色與目標系統(tǒng)之間的一次功能性交互，是體現了服務價值的功能行為。
一直以來，該如何確定業(yè)務需求層次，劃分業(yè)務需求粒度，總是眾說紛紜，沒有一個客觀的標準；業(yè)務活動將目標系統(tǒng)視為一個黑盒子，從功能性交互的完整性保證了每個業(yè)務活動都是正交的，就無需再考慮業(yè)務活動的層次和粒度，或者說，只要確定了完整性，保障了正交性，業(yè)務活動的層次與粒度也就確定下來了。
業(yè)務活動可以使用用例、用戶故事或事件風暴中的事件來表達。
業(yè)務活動是全局分析階段的基本業(yè)務單元，它的輸出對于架構映射與領域建模具有重要意義：
  架構映射：業(yè)務活動是識別限界上下文、確定上下文映射的基礎，同時，它的粒度正好對應每個限界上下文向外公開的服務契約；
  領域模型：業(yè)務需求分析細化的業(yè)務活動既是領域分析建模的重要參考，同時又作為服務場景成為場景驅動設計的起點。
全局分析是領域驅動設計統(tǒng)一過程的起點，它的目的是探索問題空間，使團隊就問題空間的價值需求和業(yè)務需求達成共識，并在統(tǒng)一語言的指導下將其清晰地呈現出來。只有問題定義清楚了，團隊才能更好地尋求解決方案。

4 領域驅動設計--架構映射
⑴ 軟件架構及映射概念
  介紹軟件架構的概念定義。
  軟件架構模式：
MVC架構、分層架構、DCI架構、CQRS架構、微服務分布式架構等。
  架構映射
架構映射成為獲得架構設計的主要設計手段。價值需求的利益相關者、系統(tǒng)愿景和系統(tǒng)范圍可映射系統(tǒng)上下文；業(yè)務服務的歸類和歸納可映射為限界上下文，系統(tǒng)上下文與限界上下文共同組成系統(tǒng)架構的重要層次，前者勾勒出解空間的控制邊界，后者勾勒出領域模型的知識邊界，組成了一個穩(wěn)定而又具有演進能力的領域驅動架構。
⑵ 系統(tǒng)上下文
系統(tǒng)上下文：以目標系統(tǒng)為核心，勾勒出用戶、目標系統(tǒng)和伴生系統(tǒng)之間的關系。
系統(tǒng)上下文的確定
  價值需求的中利益相關者可以充當系統(tǒng)上下文的用戶。
  系統(tǒng)的范圍可以幫助界定系統(tǒng)解空間的邊界，劃分目標系統(tǒng)和伴生系統(tǒng)。
  結合系統(tǒng)愿景進行判斷，與愿景不相匹配的功能和業(yè)務不考慮。
⑶ 限界上下文
限界上下文是領域驅動設計中最難解析的原則，但也是最重要的原則?？梢哉f，沒有限界上下文，就不能做好領域驅動設計。
對復雜系統(tǒng)進行分析或者綜合時可以運用的方法：自頂向下和自底向上。
限界上下文識別的步驟：分析和歸納
  業(yè)務知識的歸類
  業(yè)務知識的歸納
  業(yè)務主體的邊界梳理
  呈現限界上下文
⑷ 上下文映射
領域驅動設計強調通過深入理解業(yè)務領域，將業(yè)務模型從業(yè)務專家的角度抽象出來。然后，在應用中貫穿地使用這些模型，使開發(fā)人員和業(yè)務專家能夠更好地協(xié)同合作。
通過問題空間到解空間獲得業(yè)務維度的限界上下文，同時還要確定上下文與業(yè)務服務之間的映射關系，這對設計服務契約是限界文之間的協(xié)作關系，在領域分析建模時確定領域模型與限界上下文的關系。
上下文映射圖的可視化呈現只是一種形式，重要是限界上下文的協(xié)作模式，它們組成上下文映射模型。限界上下文之間的映射模式：客戶方/供應方、遵奉者、合作關系、共享內核、防腐層、開放主機服務、發(fā)布語言、分離方式、大泥球模式。
⑸ 服務契約設計
服務契約：在全局分析階段輸出的業(yè)務需求稱之為業(yè)務服務，業(yè)務服務滿足了角色的服務請求，在解空間體現為服務與客戶的協(xié)作關系，形成的協(xié)作接口可稱之契約。
服務契約：消息契約、服務資源契約、服務行為契約、服務事件契約。
應用服務與領域服務之間：領域層與應用界面之間引入應用層，應用層盡量簡單，不包含業(yè)務規(guī)則或者知識，只為領域層中的領域對象協(xié)調任務，分配工作，使它們互相協(xié)作；簡單理解：“應用層只負責提問，不負責回答；領域層永遠只負責回答。”應用層定義的應用服務是外觀模式的體現。
⑹ 領域驅動架構
領域驅動架構是針對領域驅動設計的一種架構風格。它以領域為核心驅動力，以業(yè)務能力為核心關注點，建立目標系統(tǒng)的結構解決方案。其核心模型為系統(tǒng)上下文與限界上下文，并以它們?yōu)檫吔?，形成各自的架構模式：系統(tǒng)分層架構和菱形架構模式。
領域驅動架構：領域驅動設計建立的一種架構風格。
  以領域為核心驅動力，以業(yè)務能力為核心關注點，建立目標系統(tǒng)解決方案。
  領域模型為驅動的核心關注點進行縱向切分自治單元。
  核心元模型以系統(tǒng)上下文與限界上下文為邊界，形成各自架構模式：分層架構和菱形對稱架構。
  限界上下文是架構映射階段的基本單元，每個限界上下文是一個自治的獨立王國（微服務）。 

5 領域驅動設計--領域建模
領域建模的過程是模型驅動設計的過程，領域建模的分析、設計和實現是循序漸進的增量和迭代的過程。
  利用抽象化繁為簡，通過標準的結構來組織和傳遞信息，形成可推演的解決方案。
  解決信息超載問題的工具，對知識進行了選擇性的簡化和有意的結構化。
  模型的重要性并不體現在它表現形式，重要是在于它傳遞的知識。 
⑴ 模型驅動設計
模型驅動設計就是把產品需求轉化成一個可以運行的系統(tǒng)，涉及產品設計、領域建模、架構設計、詳細設計、代碼編寫、測試等步驟。DDD的基本過程進一步展開來說，大體是以下三點：
  在理解產品需求的基礎上，從中提取出核心概念，然后建立起核心概念的邏輯結構，概念的邏輯結構即領域模型，領域模型以一種抽象的視角來理解復雜業(yè)務，但也僅僅是理解業(yè)務。
  有了領域模型，也有了系統(tǒng)架構，到了這一步通常還不能直接開始編碼，一般會對系統(tǒng)架構中的各個模塊進行詳細，比如模塊的流程是什么，數據結構怎么設計、DB數據表怎么設計等。
  要用代碼搭建起一套可運行的系統(tǒng)。從領域模型到代碼，通常不能一步跨越，中間需要通過系統(tǒng)架構來銜接。把領域模型映射為系統(tǒng)架構，這是至關重要的一步。簡單來說，一般都采用分層微服務架構，架構映射即是把領域模型中的概念分解到架構中的各層。
⑵ 領域分析建模
對于一個復雜的軟件系統(tǒng)，必須對問題系統(tǒng)展開分析，有的放矢這對軟件系統(tǒng)需求尋求設計上的解決方案。在戰(zhàn)略設計階段采用“全局分析”和“架構映射”，在戰(zhàn)術層面，領域驅動設計要求分析方法就是要以“領域”為中心展開分析建模，獲得領域分析模型。這個過程是以領域專家主導，與開發(fā)團隊一起共同進行分析建模，以戰(zhàn)略分析為基礎（系統(tǒng)上下文和限界上下文），再進行戰(zhàn)術設計（領域分析模型）。
領域驅動設計的關鍵是采取合理的方式對領域進行建模，也就是將物理世界的業(yè)務映射到軟件系統(tǒng)產品中，最終使得軟件產品能夠承載實際的業(yè)務?？梢詮娜缦聨讉€方面來進行領域建模：
⑶ 領域設計建模
領域設計建模：它的核心工作就是設計聚合和設計服務，最關鍵的設計要素（實體、值對象、領域服務、領域事件、聚合、工廠、資源庫）。領域驅動設計從不忽略技術因素對模型的影響，它引入戰(zhàn)術層面設計元模型，將技術與領域模型結合，避免空談對象模型的理想。
領域設計模型：只能由實體、值對象、領域服務和領域事件表示模型，避免將領域邏輯泄漏到領域層外的其它地方。
  聚合用于封裝實體和值對象，并維持自己邊界內所有對象的完整性。
  要訪問聚合，只能通過聚合根的資源庫，這就隱式地劃定了邊界和入口，有效控制了聚合內所有類型的領域對象；
  若聚合創(chuàng)建的邏輯較為復雜或存在可變性，可引入工廠來創(chuàng)建聚合內的領域對象。
  若牽涉到實體的狀態(tài)變更，領域源模型建議通過領域事件來驅動。
設計框架總體結構采用領域驅動設計的分層架構，但不同的是該結構嚴格遵循分層架構的基本原則，不允許用戶界面層越過應用層直接接觸領域層。由于領域層是領域驅動設計的核心，而其它層經常在各類分層架構中出現，已經有了比較成熟的設計方法。因此，分層架構框架主要討論領域層以及與領域層密切 相關的數據訪問模塊的設計。領域層是根據不同實際領域，利用統(tǒng)一編碼規(guī)則實現的動態(tài)結構，又可分為聚合模塊、工廠模塊和倉儲模塊三部分。數據訪問模塊屬于基礎結構層，是封裝好的靜態(tài)模塊。
⑷ 領域實現建模
代碼架構分層是經典領域驅動設計的四層：用戶接口層，應用層，領域層和基礎設施層。 
  用戶接口層：面向前端用戶提供服務和數據適配。這一層聚集了接口和數據適配相關的功能。
  應用層：實現服務組合與編排，主要適應業(yè)務流程快速變化的需求。這一層聚集了應用服務和時間訂閱相關的功能。
  領域層：實現領域模型的聚合、聚合根、實體、值對象、領域服務和領域事件對象的協(xié)同和組合形成領域模型的核心業(yè)務能力。
  基礎設施層：它貫穿所有層，為各層提供基礎資源服務。這一層聚集了各種底層資源相關的服務和能力。

6 領域驅動設計--案例分析
展示和講解5個項目案例