關于領域模型與技術架構的關系的思考

人類社會的一切事物都是來源于對造物主智慧的學習，人類本身是不會創造任何東西的。

外國新技術并不能作為軟體架構的終極準則，因為老外也是人。我認為客觀世界的架構應該是軟體架構的唯一準則，換而言之，上帝也是一個架構師，而這個客觀世界就是他的作品。

有這麼完美的學習對象，為什麼要舍本逐末呢？

就拿領域對象的設計來說，在客觀世界中，人如果要做某件事情，比如掃地這個動作，掃地難道是人自己完成的嗎？其實掃地是人借助掃帚這個工具完成的。

換而言之，領域對象的一些動作，也根本不屬于他自己，如果你把這些動作硬要強加在領域對象身上，就肯定會出現類似領域對象中調用技術層這種别扭的問題。

比如，經常有什麼貧血對象，和充血對象之類的讨論，這其實很可笑，儲存、删除、這些概念，本身是在計算機領域才存在的概念，現在大家都想把他強加在領域對象上，領域對象本身是對業務的模拟，怎麼可能有這些動作？大家也覺的不妥，于是就繞彎彎，想發明一種說法和思想，自己說服自己，讓這件事情變的合理。但是這在本質上就是錯誤的，這種追求也是徒勞的。

domain就應該隻關注于領域對象之間的關系和行為就足夠了，涉及到技術的，都交給其他層完成，而不是非要在domain中加上技術性的操作，你覺得别扭，這是必然的，因為在原本的業務概念中，根本不存在這中技術性的概念！領域對象，應該僅僅關注自身狀态和行為，以及和其他領域對象之間關系的建立，至于一切計算機領域的概念（比如儲存、删除這些概念），都不應該出現在領域對象中，因為這是違背自然規律的組合，或者說是違背業務概念的。

領域模型中的對象之間既然有關系，就肯定需要互相協作共同完成某個更大的業務邏輯；那麼如何協作呢？目前最優雅并能確定領域對象處于核心主動地位的方式是通過domain event；在c#，java這樣的語言中，對象天生并不具備發送消息和接收消息的能力，需要依賴于外部架構；而像scala的akka那種actor model，一個領域對象就是一個actor，actor能夠通過發送異步消息和其他actor通訊聯系，這種消息發送是異步的，屬于“fire-and-forget”方式。那麼在c#這樣的語言下，我們可以通過domain event也可以達到類似actor一樣的效果；

domain event是eda（event driven architecture）思想的一種展現，eda原本是用于soa（service oriented architecture）中，服務與服務之間的通信；domain event則是将eda用于領域對象之間的通信；

引入domain event主要目的是為解決如何将領域模型和技術架構進行解耦，讓領域模型不依賴于特定的技術架構實作，進而可以讓領域模型真正反映純粹的業務模型。