关于领域模型与技术架构的关系的思考

外国新技术并不能作为软件架构的终极准则，因为老外也是人。我认为客观世界的架构应该是软件架构的唯一准则，换而言之，上帝也是一个架构师，而这个客观世界就是他的作品。 有这么完美的学习对象，为什么要舍本逐末呢？ 就拿领域对象的设计来说，在客观世界中，人如果要做某件事情，比如扫地这个动作，扫地难道是人自己完成的吗？其实扫地是人借助扫帚这个工具完成的。 换而言之，领域对象的一些动作，也根本不属于他自己，如果你把这些动作硬要强加在领域对象身上，就肯定会出现类似领域对象中调用技术层这种别扭的问题。 比如，经常有什么贫血对象，和充血对象之类的讨论，这其实很可笑，保存、删除、这些概念，本身是在计算机领域才存在的概念，现在大家都想把他强加在领域对象上，领域对象本身是对业务的模拟，怎么可能有这些动作？大家也觉的不妥，于是就绕弯弯，想发明一种说法和思想，自己说服自己，让这件事情变的合理。但是这在本质上就是错误的，这种追求也是徒劳的。 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主要目的是为解决如何将领域模型和技术架构进行解耦，让领域模型不依赖于特定的技术架构实现，从而可以让领域模型真正反映纯粹的业务模型。
你真的需要防腐层吗？DDD 系统间的7种关系梳理与实践 当提到系统间交互的时候，人们都会想到大名鼎鼎的防腐层，用来防止其他系统的模型变更对本系统造成影响。但是在实践这个模式的过程中，我们常常会遇到问题。此时我们也应该考虑下其他的系统交互方式。
架构视角-到底如何做好分层 在进行程序开发和设计时我们常常提到分层的概念，但是怎么样的分层才是好的分层呢，这篇谈谈在如何分层这个问题上的一些体会，和大家探讨一下
DDD 领域驱动设计落地实践系列：工程结构分层设计 前面几篇文章中，笔者给大家阐述了 DDD 领域驱动设计的三大过程，重点围绕如何通过战略设计与战术设计进行 DDD 落地实践进行了详细的讨论，但是还没有涉及到工程层面的落地。实际上所有的这些架构理论到最后都是为了使得我们代码结构更加清晰，从而开发出 bug 少、扩展性强、逻辑清楚的应用。因此本文就是为了解决 DDD 领域驱动落地实践最后一公里问题，将我们分析出来的领域模型通过与工程结构的映射实现真正的落地。
netfocus 对DDD领域驱动设计感兴趣，在.NET/JAVA平台都有多年工作经验。架构方面专注于CQRS/Event Souring/EDA架构的研究和框架开发。热衷于开源，拥有两个个人开源项目：ENode,EQueue