最近發現下面關於上下文的理解有些問題，不太好改，暫時先不改了
承前：大型系統的支撐，應用系統開發思想的變遷，ddd實踐切入點(一)
領域模型不統一時，會有一些問題，比如：限制了整合，增加溝通成本，看上去不優雅。但大型系統領域模型完全統一並不是一種可行的經濟有效的做法。強行統一模型會遇到一些問題：
1.遺留系統模型的修改過多，風險很大；
2.協調多個小組所使用的不同模型使之統一時成本過高，開銷過大；
3.具有一些特殊需求的模組可能不得不使用無法充分滿足需求的模型，而只能講這些無法滿足的行為放到其他地方；
4.試圖用乙個模型滿足所有人需求可能會導致模型中包含過於複雜的選擇，難以使用。
是以統一模型的方式並不是乙個好辦法，在這種情況下，需要標記出不同模型之間的邊界和關係。bounded context（界限上下文）即是用來定義每個模型的應用範圍，上下文圖則用來給出專案上下文以及他們之間關係的總體檢視。申請單管理和流程流轉就可以兩個context來分別開發。需要注意的是，這樣做會引發一些問題：重複的概念和假同源。重複的概念是兩個模型元素表示的實際是同乙個概念，每當概念變化時，都必須修改兩個地方。假同源是指對不同的概念使用了相同術語。這些情況多是由上下文邊界不清晰造成的。
上下文圖可以使上下文的邊界清晰，需要注意上下文之間的**盡量不要重用，相鄰上下文不必保持同樣步調，上下文之間的整合需要通過介面或經過轉換實現。識別每個模型在專案中的作用，並定義其bounded context。包括非物件導向子系統的隱含模型。為每個bounded context命名，並把名稱新增到通用語言中。描述模型之間的接觸點，明確每次交流所需的轉換，並突出共享的內容。
圖中沒有共享內容，只是申請單將流轉所需條件資訊和流轉任務委託給流程進行處理，條件資訊中包含流轉所必須的申請單的模型，但此申請單模型和單據上下文中的申請單模型有些不同，這個不細說了。此處只是資訊單向傳送，如果有互動時，中間的流轉條件需要做雙向的資訊轉換。此外，通常多個模型在整合時可能會遇到一些障礙，有一些現成的模式用來解決這些障礙，例如：共享核心，跟隨者，隔離層，separate way(獨立自主)，open host service，published language，這些模式都是隨情況而定的，或許之後在具體情況遇到時會細說，這裡就不抄書了。隨著專案的進行，這些模式的選擇，上下文圖的組織方式都有可能發生轉變。這種轉變的過程中也可以借助大比例結構以及精煉核心領域劃分通用子領域的方式來管理模型的複雜性。精煉的一些模式有緣的話我可能會單獨整理一下，因為這次只用到了乙個抽象核心，所以就在之後和其他過程一起介紹，不單獨說了。
DDD實踐切入點 一
前兩篇 大型系統的支撐，應用系統開發思想的變遷 之前大致說了使用ddd的前期準備，現在可以真正開始實踐了，以我剛剛結束的乙個簡單的經典ddd方式的專案為例子，當然由於比較簡單，所以很多時候會脫離它來介紹一些額外情況，以及這些情況在 ddd 書上提到的解決辦法，另外，說明一下，例子的作用只是例子，只是...
市場切入點
切入點 通俗點，就是突破口，即解決某個問題時應該最先著手的地方。尋找市場切入點，主要從市場分析和產品定位兩方面來入手 接下來舉例說明如何尋找市場切入點，選擇物件 企鵝fm。1.市場分析 1 swot分析 其中，s strengths 是優勢，w weaknesses 是劣勢，o opportunit...
Spring AOP 定義切入點
首先我們編寫了通知advice，但是我們還不能表達在應用系統的什麼地方應用這些通知，切入點決定了乙個特定類的特定方法是否滿足特定規則，如果滿足則通知就應用到該方法上，spring的切入點可以讓我們靈活的定義在什麼地方應用通知。spring的切入點框架的核心介面pointcut public inte...