關於智慧型領域物件的設計，一直沒有拿出確實的例子來說明這樣程式設計的好處和優點，以及如何正確地理解這種程式設計方式。接下來我開始從傳統
service + dao
開發模式開始改造和發展，直到變化成智慧型領域物件設計的開發模式上來，對於每一種變化，我會統計出手工**編寫行數（
setter
、getter
和import
等就不在統計範圍內了），看看生產力的變化。任何生產力的提高都是體現在機械代替重複而又規律的工作上，我們選擇的案例同樣是本應該被工業化掉的東西，但還在手工勞作。
傳統的service +
dao包括三個核心類，以「使用者
」物件為例，通常包括的類：
user, userservice, userdao
。通常需要的外部支援是：
hibernate/jpa,spring
。為了演示方便忽略掉介面（如
iuserservice
），也不再區分po和
vo。事實上案例演示完成後，你會發覺這兩個東西確實很少使用。
這個例項中包含了乙個持久層框架
thin
，我先將有關持久的論述寫在這裡，你可以先看例項回頭有興趣再這段內容：所謂物件的持久就是把物件的屬性登記在資料庫中，在現實生活是經常發生的，如我們去銀行辦乙個儲蓄卡，需要填表，而填表的過程就是持久化的過程。看看這張**，便會發現所有填寫項都可以用
key-value
表示，再考察我們是如何區分現實物件，便會發現同樣是以物件的屬性為區分依據，屬性就可以用
key-value
表示，所以無論任何物件只要被持久必然可轉化成
key-value
，唯一的不同就是
key-value
的儲存方法不同而已，即：key-value是一切物件持久的介面。如果應用程式的持久方式是基於
key-value
的，那麼這種應用不僅便於更換不同的關聯式資料庫，即使是往
no-sql
資料庫上移植，縱然我對
no-sql
資料庫不甚了解，但它絕不會偏離本質。
thin
就是這麼乙個工具，把物件轉化成
key-value
，然後存入對應的表，反之亦可。
科學家通常用習慣用「美
」來衡量結論正確性，雖然沒有什麼科學依據，但也屢試不爽。key-value是一切物件持久的介面，這個結論是美的，大家可以順便考量一下
thin
的短小精幹是否也符合美的標準。
」大道若簡
」，我相信基於
key-value
的持久方式，正是持久層的「大道
」。
領域驅動設計 1 概述
領域驅動設計 隨著計算機的普及,軟體的發展也從一開始的單一計算,變為大規模,多功能的集合.這也就對軟體開發的效率,規模,可維護性提出了更多的要求,針對於軟體不同的發展階段,它的開發模式也是乙個逐漸演變的過程 瀑布開發模式 敏捷開發模式 領域驅動設計 微服務 瀑布開發模式 強調軟體規範,使用工程管理思...
領域驅動設計 1 概述
領域驅動設計 隨著計算機的普及,軟體的發展也從一開始的單一計算,變為大規模,多功能的集合.這也就對軟體開發的效率,規模,可維護性提出了更多的要求,針對於軟體不同的發展階段,它的開發模式也是乙個逐漸演變的過程 瀑布開發模式 敏捷開發模式 領域驅動設計 微服務 瀑布開發模式 強調軟體規範,使用工程管理思...
1 認識《領域驅動設計》
第一，大家應該知道領域驅動的是設計，這是必須的。領域驅動設計 顧名思義，首先強調的是 領域 這個詞不是指技術上的任何東西，而是指 業務領域 是說用領域的角度去分析和設計業務。可是在現實中我們有多少人又真的懂業務呢，那些低層次的程式設計師就不用說了，因為他們了解的業務甚至都不是第一手的，都是經過架構師...