关于领域模型与技术架构的关系的思考
人类社会的一切事物都是来源于对造物主智慧的学习，人类本身是不会创造任何东西的。
外国新技术并不能作为软件架构的终极准则，因为老外也是人。我认为客观世界的架构应该是软件架构的唯一准则，换而言之，上帝也是一个架构师，而这个客观世界就是他的作品。
有这么完美的学习对象，为什么要舍本逐末呢？
就拿领域对象的设计来说，在客观世界中，人如果要做某件事情，比如扫地这个动作，扫地难道是人自己完成的吗？其实扫地是人借助扫帚这个工具完成的。
换而言之，领域对象的一些动作，也根本不属于他自己，如果你把这些动作硬要强加在领域对象身上，就肯定会出现类似领域对象中调用技术层这种别扭的问题。
比如，经常有什么贫血对象，和充血对象之类的讨论，这其实很可笑，保存、删除、这些概念，本身是在计算机领域才存在的概念，现在大家都想把他强加在领域对象上，领域对象本身是对业务的模拟，怎么可能有这些动作？大家也觉的不妥，于是就绕弯弯，想发明一种说法和思想，自己说服自己，让这件事情变的合理。但是这在本质上就是错误的，这种追求也是徒劳的。
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主要目的是为解决如何将领域模型和技术架构进行解耦，让领域模型不依赖于特定的技术架构实现，从而可以让领域模型真正反映纯粹的业务模型。