領域驅動設計真的好嗎？由于業(yè)務分工專業(yè)，業(yè)務邏輯更加清晰，正確的業(yè)務分類有利于后續(xù)業(yè)務的拓展。領域面向對象編程使代碼工程更有凝聚力。業(yè)務邏輯分布到各個領域對象，使得對象的外部代碼更加簡潔。解決復雜的業(yè)

領域驅動設計真的好嗎？

由于業(yè)務分工專業(yè)，業(yè)務邏輯更加清晰，正確的業(yè)務分類有利于后續(xù)業(yè)務的拓展。

領域面向對象編程使代碼工程更有凝聚力。業(yè)務邏輯分布到各個領域對象，使得對象的外部代碼更加簡潔。

解決復雜的業(yè)務邏輯編寫問題。通過領域劃分，分散業(yè)務邏輯編寫，集中處理某個領域的業(yè)務。

域驅動模式使用面向對象模式編程，使代碼更具語義。

領域驅動設計模式已經提出很多年了，為什么不流行呢？

近年來，越來越多的公司追求領域驅動設計。

領域驅動有一個前提，那就是專業(yè)建模。事實上，項目通常分為模塊。這里的部門有同樣的含義，但它只是足夠專業(yè)。

微服務的出現也反映了業(yè)務領域的劃分。

域驅動的一個關鍵點是模型包含行為。在MVC模式下，這是服務模型層。

屬性和行為的分離使并行開發(fā)成為可能，并避免由提交相同代碼文件的不同人員引起的沖突。

綜上所述，除了面向對象編程，特性設計模式也可以在MVC模式中看到。但在模型中，面向對象編程不利于團隊開發(fā)，也不一定是一個好的選擇。

復雜問題簡化，單元函數簡化，復雜函數組合表達。

謝謝

如何使用Rose UML建模，建抽象類的圖，急？

我明白你的意思。抽象類和公共類一般用UML表示，抽象類用粗線框或雙線框表示。但是rose沒有這個函數，在派生中也找不到抽象類。

只有一種解決方案，即先將其表示為普通類，然后在類名前添加這樣一個符號：>

這符合UML語法規(guī)則，并用它來表示抽象類。>是一種派生，表示抽象類。

請注意，>不是中文輸入狀態(tài)下的書名，而是英文輸入狀態(tài)下的大于號和小于號，稱為雙尖符號。

請注意，以這種方式表示的抽象類不能在正向工程中顯示，這比不顯示要好。