❶ 領域模型的核心元素
業務角色顯示了一個人承擔的一系列職責。業務實體表示使用或產生的可交付工回件、資源和事件。業務答用例實現顯示了協作的業務角色和業務實體如何執行某個工作流程。使用以下幾種圖來記錄業務用例實現： 圖顯示參與的業務角色和業務實體。活動圖，其中泳道顯示業務角色的職責，而對象流顯示如何在工作流程中使用業務實體。 序列圖描述業務角色和業務主角之間交互的詳細情況，並顯示如何在業務用例執行過程中訪問業務實體。
業務對象模型將結構的概念和行為的概念結合了起來。
它是一個紐帶工件，用於對業務關系進行清晰的表述，表述方式與軟體開發人員的思考方式類似，同時仍保留一些純粹的業務內容。將我們所知道的有關業務的信息按照對象、屬性和職責進行了合並。
它探索業務領域知識的本質，所採用的方式使我們能夠從對業務問題的思考轉變到對軟體應用程序的思考上來。
它是一種確定需求的方法，使需求能夠為待建信息系統使用，並得到該系統的支持。
確定業務對象定義、對象間關系、對象名稱和對象間關系名稱的流程使我們能夠以一種能被業務領域專家理解和驗證的精確方式來表達業務領域知識。
❷ 不就是一個訂票網站嗎，12306的核心模型設計思路究竟復雜在哪兒
12306這個系統，核心要解決的問題是網上售票。涉及到2個角色使用該系統：用戶、鐵道部。用戶的核心訴求是查詢余票、購票；鐵道部的核心訴求是 售票。購票和售票其實是一個場景，對用戶來說是購票，對鐵道部來說是售票。因此，我們要設計一個在線的網站系統，解決用戶的查詢余票、購票，以及鐵道部的 售票這3個核心訴求。看起來，這3個場景都是圍繞火車票展開的。
查詢余票：用戶輸入出發地、目的地、出發日三個條件，查詢可能存在的車次，用戶可以看到每個車次經過的站點名稱，以及每種座位的余票數量。
購票：購票分為訂票和付款兩個階段，本文重點分析訂票的模型設計和實現思路。
其實還有很多其他的需求，比如給不同的車次設定銷售座位數配額，以及不同的區段設置不同的限額。但相比前面兩個需求來說，我覺得這個需求相對次要一些。
需求分析
確實，12306也是一個電商系統，而且看起來商品就是票了。因為如果把一張票看成是一個商品，那購票就類似於購買商品，然後每張票都有庫存，商品 也有庫存的概念。但是如果我們仔細想想，會發現12306要復雜很多，因為我們無法預先確定好所有的票，如果非要確定，那隻能通過窮舉法了。
我們以北京西到深圳北的G71車次高鐵為例（這里只考慮南下的方向，不考慮深圳北到北京西的，那是另外一個車次，叫G72），它有17個站（北京西 是01號站，深圳北是17號站），3種座位（商務、一等、二等）。表面看起來，這不就是3個商品嗎？G71商務座、G71一等座、G71二等座。大部分輕 易噴12306的技術人員（包括某些中等規模公司的專家、CTO）就是在這里栽第一個跟頭的。實際上，G71有136*3=408種商品（408個 SKU），怎麼算來的？如下：
如果賣北京西始發的，有16種賣法（因為後面有16個站），北京西到：保定、石家莊、鄭州、武漢、長沙、廣州、虎門、深圳。。。。都是一個獨立的商 品，同理，石家莊上車的，有15種下車的可能，以此類推，單以上下車的站來計算，有136種票：16+15+14….+2+1=136。每種票都有3種座 位，一共是408個商品。
為了方便後面的討論，我們先明確一下票是什麼？
一張票的核心信息包括：出發時間、出發地、目的地、車次、座位號。持有票的人就擁有了一個憑證，該憑證表示持有它的人可以坐某個車次的某個座位號， 從某地到某地。所以，一張票，對用戶來說是一個憑證，對鐵道部來說是一個承諾；那對系統來說是什麼呢？不知道。這就是我們要分析業務，領域建模的原因，我 們再繼續思考吧。
明白了票的核心信息後，我們再看看G71這個車次的高鐵，可以賣多少張票？
討論前先說明一下，一輛火車的物理座位數（站票也可以看成是一種座位，因為站票也有數量配額）不等於可用的最大配合。所有的物理座位不可能都通過 12306網站來銷售，而是只會銷售一部分，比如40%。其餘的還是會通過線下的方式銷售。不僅如此，可能有些站點上車的人會比較多，有些比較少，所以我 們還會給不同的區間配置不同的限額。比如D31 北京南至上海共有765張，北京南有260張，楊柳青有80張，泰安有76張。如果楊柳青的80張票售完就會顯示無票，就算其他站有票也會顯示無票的。每 個車次肯定會有各種座位的配額和限額的配置的，這種配置我目前無法預料，但我已經把這些規則都封裝近車次聚合根里了，所有的配置策略都是基於座位類型、站 點、區間配置的。關於票的配置抽象出來，我覺得主要有3種：1）某個區段最多允許出多少張；2）某個區段最少允許出多少張；3）某個站點上車的最多多少 張；當用戶訂票時，把用戶指定的區段和這3種配置條件進行比較，3個條件都滿足，則可以出票。不滿足，則認為無票了。下面舉個例子：
ABCDEFG，這是所有站點。座位總配額是100，假設B站點上車，E站下車的人比較少，那我們就可以設定BE這個區段最多隻能出10張票。所 以，只要是用戶的訂票是在這個區段內的，就最多出10張。再比如，一列車次，總共100個座位配額，希望全程票最少滿足80張，那我們只要給AG這個區段 設定最少80張。那任何訂票請求，如果是子區間的，就不能超過100-80，即20張。這兩種條件必須同時滿足，才允許出票。
但是，不管如何做配額和限額，我們總是針對某個車次進行配置，這些配置只是車次內部售票時的一些額外的判斷條件（業務規則），不影響車次模型的核心 地位和對外暴露的功能。所以，為了本文討論的清楚起見，我後續的討論都不涉及配額和限額的問題，而是認為任何區段都可以享受火車最大的物理座位數。
並且，為了討論問題方便，我們減少一些站點來討論。假設某個車次有A,B,C,D四個站點。那001這個人購買了A,B這個區間，系統會分配給 001一個座位x；但是因為001坐到B站點後會下車，所以相當於x這個座位又空出來了，也就是說，從B站點開始，系統又可以認為x這個座位是可用的。所 以，我們得出結論：同一個座位，其實可以同時出售AB,BC這兩張票。通過這個簡單的分析，我們知道，一列火車雖然只有有限的座位數，比如1000個座 位。但可以賣出的票遠遠不止1000個。還是以A,B,C,D四個站點為例，假如火車總共有1000個座位，那AB可以賣1000張，BC也可以賣 1000張，同樣，CD也可以賣1000張。也就是說，理論上最多可以賣出3000張票。但是如果換一種賣法，所有人都是買ABCD的票，也就是說所有的 票都是經過所有站點的，那就是最多隻能賣出1000張票了。而實際的場景，一定是介於1000到3000之間。然後實際的G71這個車次，有17個站，那 到底可以賣出多少個票，大家應該可以算了吧。理論上這17個站中的任意兩個站點之間所形成的線段，都可以出售為一張票。我數學不好，算不太清楚，麻煩有數 學好的人幫我算算，呵呵。
通過上面的分析，我們知道一張票的本質是某個車次的某一段區間（一條線段），這個區間包含了若干個站點。然後我們還發現，只要區間不重疊，那座位就不會發生競爭，可以被回收利用，也就是說，可以同時預先出售。
另外，經過更深入的分析，我們還發現區間有4種關系：1）不重疊；2）部分重疊；3）完全重疊；4）覆蓋；不重疊的情況我們已經討論過了，而覆蓋也 是重疊的一種。所以我們發現如果重疊，比如有兩個區間發生重疊，那重疊部分的區間（可能誇一個或多個站點）是在爭搶座位的。因為假設一列火車有100個座 位，那每個原子區間（兩個相鄰站點的連線），最多允許重疊99次。
所以，經過上面的分析，我們知道了一個車次能夠出售一張車票的核心業務規則是什麼？就是：這張車票所包含的每個原子區間的重疊次數加1都不能超過車次的總座位數，實際上重疊次數+1也可以理解為線段的厚度。
模型設計
上面我分析了一下票的本質是什麼。那接下來我們再來看看怎麼設計模型，來快速實現購票的需求，重點是怎麼設計商品聚合以及減庫存的邏輯。
傳統電商的思路
如果按照普通電商的思路，把票（站點區間）設計為商品（聚合根），然後為票設計庫存數量。我個人覺得是很糟糕的。因為一方面這種聚合根非常多（上面 的G71就有408個）；另一方面，即便枚舉出來了，一次購票也一定會影響非常多其他聚合根的庫存數量（只要被部分或全部重疊的區間都受影響）。這樣的一 次訂單處理的復雜度是難以評估的。而且這么多聚合根的更新要在一個事務里，這不是為難資料庫嗎？而且，這種設計必然帶來大量的事務的並發沖突，很可能導致 資料庫死鎖。總之，我認為這種是典型的由於領域模型的設計錯誤，導致並發沖突高、數據持久化落地困難。或者如果要解決並發問題，只能排隊單線程處理，但是 仍然解決不了要在一個事務里修改大量聚合根的尷尬局面。聽說12306是採用了Pivotal Gemfire這種高大上的內存資料庫，我對這個不太了解。我不可想像要是不使用內存資料庫，他們要怎麼實現車次內的票之間的數據強一致性（就是保證所有 出售的票都是符合上面討論的業務規則的）？所以，這種設計，我個人認為是思維定勢了，把火車票看成是普通電商的商品來看待。所以，我們有時做設計又要依賴 於經驗，又要不能被以往經驗所束縛，真的不容易，關鍵還是要根據具體的業務場景多多深入分析，盡量分析抽象出問題的本質出來，這樣才能對症下葯。那是否有 其他的設計思路呢？
我的思路
聚合設計
通過上面的分析我們知道，其實任何一次購票都是針對某個車次的，我認為車次是負責處理訂票的聚合根。我們看看一 個車次包含了哪些信息？一個車次包括了：1）車次名稱，如G71；2）座位數，實際座位數會分類型，比如商務座20個，一等座200個；二等座500個； 我們這里為了簡化問題，可以暫時忽略類型，我認為這個類型不影響核心的模型的設計決策。需要格外注意的是：這里的座位數不要理解為真實的物理座位數，很有 可能比真實的座位數要少。因為我們不可能把一個車次的所有座位都在網上通過12306來出售，而是只出售一部分，具體出售多少，要由工作人員人工指定。 3）經過的站點信息（包括站點的ID、站點名稱等），注意：車次還會記錄這些站點之間的順序關系；4）出發時間；看過GRASP九大模式中的信息專家模式的同學應該知道，將職責分配給擁有執行該職責所需信息的類。我們這個場景，車次具有一次出票的所有信息，所以我們應該把出票的職責交給車次。另外學過DDD的同學應該知道，聚合設計有一個原則，就是：聚合內強一致性，聚合之間最終一致性。經 過上面的分析，我們知道要產生一張票，其實要影響很多和這個票對應的線段相交的其他票的可用數量。因為所有的站點信息都在車次聚合內部，所以車次聚合內部 自然可以維護所有的原子區間，以及每個原子區間的可用票數（相當於是庫存數）。當一個原子區間的可用票數為0的時候，意味著火車針對這個區間的票已經賣完 了。所以，我們完全可以讓車次這個聚合根來保證出票時對所有原子區間的可用票數的更新的強一致性。對於車次聚合根來說，這很簡單，因為只是幾次簡單的內存 操作而已，耗時可以忽略。一列火車假如有ABCD四個站點，那原子區間就是3個。對於G71，則是16個。
怎麼判斷是否能出票
基於上面的聚合設計，出票時扣減庫存的邏輯是：
根據訂單信息，拿到出發地和目的地，然後獲取這段區間里的所有的原子區間。然後嘗試將每個原子區間的可用票數減1，如果所有的原子區間都夠減，則購 票成功；否則購票失敗，提示用戶該票已經賣完了。是不是很簡單呢？知道了出票的邏輯，那退票的邏輯也就很簡單了，就是把這個票的所有原子區間的可用票數加 1就OK了。如果我們從線段的厚度的角度去考慮，那出票時，每個原子區間的厚度就是+1，退票時就是減一。就是相反的操作，但本質是一樣的。
所以，通過這樣的思路，我們將一次訂票的處理控制在了一個聚合根里，用聚合根內的強一致性的特性保證了訂票處理的強一致性，同時也保證了性能，免去 了並發沖突的可能性。傳統電商那種把票單做類似商品的核心聚合根的設計，我當時第一眼看到就覺得不妥。因為這違背了DDD強調的強一致性應該由聚合根來保 證、聚合根之間的最終一致性通過Saga來保證的原則。
還有一個很重要的概念我想說一下我的看法，就是座位和區間的關系。因為有些朋友和我講，考慮座位號的問題，雖然都能減1，座位號也必須是同一個。我 覺得座位是全局共享的，和區段無關（也許我的理解完全有誤，請大家指正）。座位是一個物理概念，一個用戶成功購買了一張票後，座位就會少一個，一張票唯一 對應一個座位，但是一個座位有可能會對應多張票；而區間是一個邏輯上的概念，區間的作用有兩個：1）表示票的出發地和目的地；2）記錄票的可用數額。如果 區間能連通（即該區間內的每個原子區間的可用數額都大於0），則表示允許擁有一個座位。所以，我覺得座位和票（區間）是兩個維度的概念。
如何為票分配座位
我覺得車次聚合根內部應該維護所有該車次已經售出的票，已經出售的票的的本質是區間和座位的對應關系。系統處理訂票時，用戶提交過來的是一段區間。所以，系統應該做兩個事情：
先根據區間去判斷是否有可用的座位；
如果有可用座位，則再通過演算法去選擇一個可用的座位；
當得到一個可用座位後，就可以生成一張票了，然後保存這個票到車次聚合根內部即可。下面舉個例子：
假設現在的情況是座位有3個，站點有4個
座位：1,2,3
站點：abcd
票的賣法1：
票1：ab,1
票2：bc,2
票3：cd,3
票4：ac,3
票5：bd,1
這種選座位的方式應該比較高效，因為總是優先從座位池裡去拿座位，只有在萬不得已的時候才會去回收可重復利用的票。
上面的4，5兩個票，就是考慮回收利用的結果。
票的賣法2：
票1：ab,1
票2：bc,1
票3：cd,1
票4：ac,2
票5：bd,3
這種選座位的方式應該相對低效，因為總是優先會去掃描是否有可回收的座位，而掃描相對直接從座位池裡去拿票總是成本相對要高的。
上面的2，3兩個票，就是考慮回收利用的結果。
但是，優先從座位池裡拿票的演算法有缺陷，就是會出現雖然第一步判斷認為有可用的座位，但是這個座位可能不是全程都是同一個座位。舉例：
假設現在的情況是座位有3個，站點有4個
座位：1,2,3
站點：abcd
票的賣法3：
票1：ab,1
票2：bc,2
票3：cd,3
現在如果有人要買ad的票，那可用的座位有2，或者3。但是無論是2還是3，都要這個乘客中途換車位。比如賣給他座位2，那他ab是坐的座位2，但是bc的時候要坐座位1的。否則拿票2的那個人上車時，發現座位2已經有人了。而通過優先回收利用的演算法，是沒這個問題的。
所以，從上面的分析我們也知道選座位的演算法該怎麼寫了，就是採用優先回收利用座位的演算法。我認為不管我們這里怎麼設計演算法，都不影響大局，因為這一切都只發生在車次聚合根內部，這就是預先設計好聚合根，明確出票職責在哪個對象上的好處。
模型分析總結
我認為票不是核心聚合根，票只是一次出票的結果，一個憑證而已。
12306真正的核心聚合根應該是車次，車次具有出票的職責，一次出票具體做的事情有：
判斷是否可出票；
選擇可用的座位；
更新一次出票時所有原子區間的可用票數，用於判斷下次是否能出票；
維護所有已售出的票，用於為選擇可用座位提供依據；
通過這樣的模型設計，我們可以確保一次出票處理只會在一個車次聚合根內進行。這樣的好處是：
不需要依賴資料庫事務就能實現數據修改的強一致性，因為所有修改只在一個聚合根內發生；
在保證數據強一致性的同時還能提供很高的並發處理能力，具體設計見下面的架構設計；
架構設計（非本文重點，沒興趣的朋友可以略過）
我覺得12306這樣的業務場景，非常適合使用CQRS架構；因為首先它是一個查多寫少、但是寫的業務邏輯非常復雜的系統。所以，非常適合做架構層面的讀寫分離，即採用CQRS架構。而且應該使用數據存儲也分離的CQRS。這樣CQ兩端才可以完全不需要顧及對方的問題，各自優化自己的問題即可。我們可以在C端使用DDD領域模型的思路，用良好設計的領域模型實現復雜的業務規則和業務邏輯。而Q端則使用分布式緩存方案，實現可伸縮的查詢能力。
訂票的實現思路
同時藉助像ENode這樣的框架，我們可以實現in-memory + Event Sourcing的架構。Event Sourcing技術，可以讓領域模型的所有狀態修改的持久化統一起來，本來要用ORM的方式保存聚合根最新狀態的，現在只需要簡單的通用的方式保存一個 事件即可（一次訂票只涉及一個車次聚合根的修改，修改只產生一個事件，只需要持久化一個事件（一個JSON串）即可，保證了高性能，無須依賴事務，而且通 過ENode可以解決並發問題）。我們只要保存了聚合根每次變化的事件（事件的結構怎麼設計，本文不做多的介紹了，大家可以思考下），就相當於保存了聚合 根的最新狀態。而正是由於Event Sourcing技術的引入，讓我們的模型可以一直存活在內存中，即可以使用in-memory技術。不要小看in-memory技術，in- memory技術在某些方面對提高命令的處理性能非常有幫助。比如就以我們車次聚合根處理出票的邏輯，假設某個車次有大量的命令發送到分布式消息隊列，然 後有一台機器訂閱了這個隊列的消息，然後這台機器處理這個車次的訂票命令時，由於這個車次聚合根一直在內存，所以就省去了每次要去資料庫取出聚合根的步 驟，相當於少了一次資料庫IO。這樣的好處是，因為一個車次能夠真正出售的票是有限的，因為座位就那麼幾個，比如就1000個座位，估計一般正常情況也就 出個2000個左右的票吧（具體能出多少張票要取決於區間的相交程度，上面分析過）。也就是說，這個聚合根只會產生2000個事件，也就是說只會有 2000個訂票命令的處理是會產生事件，並持久化事件；而其餘的大量命令，因為車次在內存計算後發現沒有餘票了，就不會做任何修改，也不會產生領域事件， 這樣就可以直接處理下一個訂票命令了。這樣就可以大大提高處理訂票命令的性能。
另外一個問題我覺得還需要提一下，因為用戶訂票成功後，還需要付款。但用戶有可能不去付款或者沒有在規定的時間內完成付款。那這種情況下，系統會自 動釋放該用戶之前訂購的票。所以基於這樣的需求，我們在業務上需要支持業務級別的2pc。即先預扣庫存，也就是先佔住這張票一定時間（比如15分鍾），然 後付款成功後再真實給你這張票，系統做真正的庫存修改。通過這樣的預扣處理，可以保證不會出現超賣的情況。這個思路其實和傳統電商比如淘寶這樣的系統類 似，我就不多展開了，我之前寫的Conference案例也是這樣的思路，大家有興趣的可以去看一下我之前錄制的視頻。
查詢余票的實現思路
我覺得余票的查詢的實現相對簡單。雖然對於12306來說，查詢的請求佔了80%，提交訂單的請求只佔20%。但查詢由於對數據沒有修改，所以我們 完全可以使用分布式緩存來實現。我們只需要精心設計好緩存的key即可；緩存key的多少要看成本，如果所有可能的查詢都設計對應的key，那時間復雜度 為1，查詢性能自然高；但代價也大，因為key多了。如果想key少一點，那查詢的復雜度自然要上去一點。所以緩存設計無非就是空間換時間的思路。然後， 緩存的更新無非就是：自動失效、定時更新、主動通知3種。通過CQRS架構，由於CQ兩端是事件驅動的，當C端有任何狀態變化，都會產生對應的事件去通知 Q端，所以我們幾乎可以做到Q端的准實時更新。
同時由於CQ兩端的完全解耦，Q端我們可以設計多種存儲，如資料庫和緩存（Redis等）；資料庫用於線下維護關系型數據，緩存用戶實時查詢。數據 庫和緩存的更新速度相互不受影響，因為是並行的。對同一個事件，可以10台機器負責更新緩存，100台機器負責更新資料庫。即便資料庫的更新很慢，也不會 影響緩存的更新進度。這就是CQRS架構的好處，CQ的架構完全不同，且我們隨時可以重建一種新的Q端存儲。不知道大家體會到了沒有？
關於緩存key的設計，我覺得主要從查詢余票時傳遞的信息來考慮。12306的關鍵查詢是：出發地、目的地、出發日期三個信息。我覺得有兩種key 的設計思路：1）直接設計了該查詢條件的key，然後快速拿到車次信息，直接返回；這種方式就是要求我們系統已經枚舉了所有車次的所有可能出現的票（區 間）的緩存key，相信你一定知道這樣的key是非常多的。2）不是枚舉所有區間，而是把每個車次的每個原子區間（相鄰的兩個站點所連成的直線）的可用票 數作為key。這樣，key就非常少了，因為車次假如有10000個，然後每個車次平均15個區間，那也就15W個key而已。當我們要查詢時，只需要把 用戶輸入的出發地和目的地之間的所有原子區間的可用票數都查出來，然後比較出最小可用票數的那個原子區間。則這個原子區間的可用票數就是用戶輸入的區間的 可用票數了。當然，到這里我提到考慮出發日期。我認為出發日期是用來決定具體是哪個車次聚合根的。同一個車次，不同的日期，對應的聚合根實例是不同的，即 便是同一天，也可能有多個車次聚合根，因為有些車次一天有幾班的，比如上午9點發車的一班，下午3點發車的一般。所以，我們也只要把日期也作為緩存key 的一部分即可。
❸ 什麼叫業務邏輯
業務邏輯是在智能網中，對利用積木式組件（SIB）和基本呼叫處理（BCP）模塊的組合來完成每項業務特徵的過程描述。
智能網是用於生成和提供電信新業務的網路結構體系。主要由業務交換點、業務控制點、業務管理點和業務創建點組成。主要目標是實現新業務的快速引入。
業務邏輯是在智能網中，對利用積木式組件(SIB)和基本呼叫處理(BCP)模塊的組合來完成每項業務特徵的過程描述。
智能網業務邏輯在不同的平面中有不同的表示，在總功能平面中，有一組總業務邏輯(GSL)，它說明了完成各個業務獨立模塊(SIB)鏈接在一起的次序；
在分布功能平面中，分布業務邏輯(DSL)是實現SIB功能時各個功能實體的動作和各個功能實體間的信息流；在物理平面中，包含業務控制功能(SCF)的物理實體執行業務邏輯程序。通信有限狀態機模型是由表示進程的有限狀態機和表示進程之間通道的先進先出隊列(FIFO)組成。
(3)網上購物系統領域模型擴展閱讀：
業務邏輯層又可以細分為業務實體、業務組件和業務工作流。
業務實體(Entity)相當於以面向對象的類實例來代表資料庫中的實體，可能使用過DataReader或者Dataset之類的對象來代表資料庫中訪問的行，不過，在使用這些對象時，需要通過列名稱或索引來訪問各列中的數據。
這將導致使用這些對象的頁面與資料庫實現耦合。通過編寫一個實體層，將這種耦合性轉移到了業務邏輯層中；於是，如果資料庫發生了某些變動，可以修改業務邏輯層，而不需要維護頁面層。
實體層中，不會包含業務邏輯；實體只是一個數據的集合體。
業務組件負責業務規則(例如，計算稅率、折扣等)，同時負責實體層到數據訪問層的過渡工作。
❹ 領域模型的設計
舉一個簡單的例子來說明如何進行領域模型設計。
假如我們要為一個小賣店設計一套進銷存系統，她為我們提供的業務描述是這樣的：每天凌晨從布吉農批市場買蘋果、梨、葡萄、橘子、香蕉、荔枝、核桃等等，反正哪些好賣她就買回來賣。葡萄、荔枝不能長久保留，一般要當天賣出去…。
針對上面這段業務描述，我們怎麼進行領域模型設計？我給出以下幾個步驟來完成領域模型設計。
總結業務描述中的名詞
首先建一個名詞表，把涉及到的名詞列出來：
序號名詞備注；
1. 布吉農批市場
2. 買東西的人是一個隱含的名詞，每天凌晨從農批市場拿貨
3. 蘋果
4. 梨
5. 葡萄
6. 橘子
7. 香蕉
8. 荔枝
9. 核桃
10. 顧客是一個隱含的名詞，買回來賣的對象
11. 凌晨、當天時間名詞，與實體及角色無關
這個名詞列表包括了業務的行為主體：角色，以及業務過程中的操作實體：模型，對我們接下來的用例描述、領域模型分析、需求分析很有幫助。當然這個名詞列表需要經過進一步分析提煉，成為領域模型
確定業務實體
序號名詞描述；
1. 布吉農批市場不是本業務的一個實體
2. 買東西的人是本業務的一個角色
3. 蘋果是一個實體
4. 梨是一個實體
5. 葡萄是一個實體
6.橘子是一個實體
7. 香蕉是一個實體
8. 荔枝是一個實體
9. 核桃是一個實體
10. 顧客是本業務的一個角色
11. 凌晨、當天時間名詞，與實體及角色無關
❺ 領域模型和系統順序圖描述的是現實世界還是軟體系統，為什麼
可以下載trufun plato，就是eclipse的插件，是專業的uml2.2建模工具，可以專到官方網站www.trufun.net免費屬下載
❻ 用c#做一個用戶管理系統,領域模型怎麼設計
用C#做一個用戶管理系統，領域模型怎麼設計的建議：1.計算機畢業版設計可不能馬虎，最好還是自權己動動腦筋，好好的寫一寫。 2.網上那種免費的畢業設計千萬不能採用，要麼是論文不完整，要麼是程序運行不了，最重要的是到處都是，老師隨時都可以知道你是在網上隨便下載的一套3.如果沒有時間寫，可以在網上找找付費的，我們畢業的時候也是為這個頭疼了很長時間，最後在網上找了很久，終於購買了一套畢業設計，還算不錯，開題報告+論文+程序+答辯演示都有，主要的都是他們技術做好的成品，保證論文的完整和程序的獨立運行，可以先看了作品滿意以後再付款，而且同一學校不重復，不存在欺騙的性質，那個網站的名字我記的不是太清楚了，你可以在網路或者GOOGLE上搜索------七七論文,希望您可以找到
❼ .NET 什麼是領域模型
領域抄模型和.net么有關系
領域模型是領域驅動設計中的模型，脫離領域驅動設計談領域模型沒啥意義。
領域驅動設計就是把你要乾的事，抽象為一個領域。
領域模型呢，就是這個領域中的一個活生生的實體。他有屬性，有行為。
比如銀行轉賬系統，銀行轉賬是一個領域，就可以把用戶創建為一個模型，他可以有存款，取款，借出等行為
這是面向對象的一種升華
❽ 領域模型的總結
領域模型設計是需求分析的關鍵步驟。它幫助用戶及需求分析人員建立業內務概念，確定容用戶業務的問題域，系統涉及的業務范圍等等。
領域模型設計的步驟為：
1. 從業務描述中提取名詞；
2. 從提取出來的名詞中總結業務實體，區分名詞中的屬性、角色、實體、實例，形成問題域中操作實體的集合；
3. 從業務實體集合中抽象業務模型，建立問題域的概念（例如在前面的例子中，我們把容易變質的水果稱之為「短期保持水果」，當然也可以是其它說法，只要能跟用戶達成共識即可）；
4. 用UML提供的方法和圖例進行領域模型設計、確定模型之間的關系；