领域驱动设计建模思考与实践

    软件的核心是为用户解决领域相关的问题的能力，其他特性都要服务于这个基本目的。 领域驱动设计告诉我们如何做好业务层， 并以领域驱动设计思想来选择合适的框架，通过关注领域模型而不是技术来创建更好的软件。 领域模型是通过逐步演化学习得来的，这当中体现了对相关领域知识的提炼归纳，是无法复制抄袭的，是整套软件最具价值的部分。软件设计的目的是研究如何使用计算机来解决实际（领域）问题，而不是去研究数据应该如何保存更合理。数据模型主要用于描述领域模型对象的持久化方式，应该是先有领域模型才有数据模型，领域模型通过某种映射而产生相应的数据模型。什么是模型？模型是简化、是对现实世界的解释，把与解决问题相关的方面抽象出来忽略无关的细节，它是用于解决信息超载问题的工具。模型是一种知识形式，对知识进行有目的地简化和有目的地结构化，建模不是对事物的模拟，而更像是在制作电影--出于某种目的而概括地反映现实。

    领域驱动设计中 领域模型 =  数据结构 +  操作方法(仅仅只有Set、Get属性值的方法称作贫血模型，加入了自身行为方法后称作充血模型)，这样才有了一个富有生命力的完整的对象，数据则是领域模型的血液。在DDD倡导的充血模型的开发模式下，对象不仅仅只是一个记录事实结果的工具，而是一个个活生生的能够拥有自己个体行为以及能够和其他对象交互的交互行为对象。此时，对象不仅可以记录事实结果，而且表示事实发生的原因，即对象之间的相互交互协作，即这个事实结果是通过怎样的事实产生的，领域内发出的事件一定是告诉别人我发生了什么而不是请帮我做什么。因此，基于DDD思想的对象不仅可以表示事实的结果，还能表示事实本身，对象交互指软件领域模型中各个具有一定客观性的对象之间的交互。

    那么相比传统编程建模方式，领域驱动建模有什么不同呢？

    传统的编程方式下首先思考的是数据，将数据从对象的行为当中分离出来，然后根据数据去建模建立成数据库表等。

在领域驱动设计当中，首先关键考虑的是统一语言，并把统一语言用在代码当中思考我们的模型能够做什么？然后逐步地暴露出其行为，再根据行为联系到数据。有了行为才有数据而不是通过数据去倒推行为。在此基础上自然就产生出了关注分离，有了CQRS架构(命令与查询职责分离)。在写操作中我们考虑由哪些功能函数会改变系统哪些状态，而读操作中我们考虑在什么地方为用户展现什么样的视图。所以强调考虑业务过程而不是数据。

    在计算机科学当中，最难的两件事情是命名和缓存失效，在DDD的实践当中，这两件事情都将会遇到。

    命名体现了领域模型的提炼过程，即聚合的边界划分：找到内聚性强的结构然后以该结构为边界对系统进行划分，当聚合体的名称确定后聚合内部的实体与值对象的名称自然也能确定了。命名问题指的是逻辑一致性问题，只有发现事物内在的逻辑一致性时才能给该事物起名。在DDD当中一个聚合边界内实现严格的一致性，聚合体之间实现最终一致性的更新。

    缓存失效则涉及实体状态的变化，现代计算机工业采取有态和无态的划分方式，这意味需要分析找出聚合当中的可变状态与不可变状态分开进行处理。缓存冗余失效谈的是复制一致性的问题，在分布式环境当中如何取得可用性、分区容错性和一致性的平衡需要考虑。

     当命名好领域模型进入计算机代码实施时，领域模型对象是生存在计算机的In-memory cache当中。领域模型对象的状态是经常会被事件改变的，自然不可避免会遭遇状态在 缓存当中失效即更新问题，更新之后的缓存失效又将导致数据的一致性等问题。当一个复杂系统解决了命名和缓存失效问题才意味着系统走向成熟稳定，将具有良好的可扩展性和可维护性。