#原创分享# DDD领域建模--【实体】持久化

       讲解完【值对象】与【实体】，我们可以了解到他们之间的区别与联系，以及他们各自的适用场景。在一些场景下【实体】的唯一性可以用【值对象】进行表达。本文主要分享一下【实体】的持久化操作，在这里强烈推荐  Spring-Data-JDBC  面向DDD的数据框架，该框架实现了 【实体】【聚合】以及【事件】之间的关系以及他们的触发机制。基本是基于DDD思想的代码实现。

       【实体】创建完毕后，最终都要基于某种技术对其进行持久化，存储含【实体】的【数据】以及当时的【状态】，以便于在需要的时候，可以从持久化的介质中还原，从存储的【断点】处，保证程序可以继续执行。 这就是【实体】持久化最原始的目的，围绕这个目的的实现，我们可以采用多种持久化的手段实现：1、基于内存，2、基于文档   3、基于数据库（关系型、文档型等） ......。不同的存取方式各有利弊，目前我们主体都是基于 关系型数据库进行【实体】的持久化实现。

    1、  基于数据库的持久化，不得不提到大名顶顶的ORM框架（Hibernate、JPA）等是类似的框架，对象的每个属性，映射数据库的具体列字段，自动生成SQL完成数据库的持久化，不得不说其功能的强大。我们在使用这些框架的时候，不知不觉就陷入一种思维定性：数据库的使用定性。一想到【实体】建模，第一就是考虑数据库的表结构以及存储本身，忽略我们对【实体】本身应该聚焦的考虑因素：如【唯一性】、【行为】、【关键属性】等。

   2、在一定程序需要把DB看作Document，并不是每个字段都只存储一个业务属性，当前我采用大量json格式的字符串存储到一个字段中,在这个角度看，持久化时过程，保存的结果时目的。站在DBA的脚本肯定会疯掉的。

    2、保存、修改、删除【实体】等这些都需要进行持久化操作，这些操作都因该支持幂等操作，如果更新的【实体】与持久化到数据库中的【实体】是相等的，那么该操作本身是应该被忽略的。

   3、保存对象不再是一个【实体】，而是一个【聚合】的时候，需要引入事务的概念，在DDD模型下，这个处理比较棘手一些，目前的事务都基于单个数据库的场景进行讨论，目前Spring框架的事务处理机制提供的比较的普遍一些，也支持多种不同场景的策略模式。分布式模式下，事务就需要采用其他的模式或者编程技巧进行额外的处理。

   4、持久化【实体】或者其他，不仅仅要持久化对象本身，还需要持久当时的业务上下文，便于下次还原时，顺带还原当时的业务上下文。

   目前，对我而言，持久化时存储，可以把【实体】当作时图书，DB则是图书馆，每次借书、还书都采用图书馆里的管理模式，

   DDD 领域思想，持久化强调了幂等的重要性，对象当时运行的上下文以及如何写入与读取这些信息，可能时【值对象】、【实体】或者【聚合】等。以及基于领域的事件驱动模型的建立。提前讲解一下  DDD比较推崇的一些架构实现时采用 CQRS 模式。与事件驱动密闭可分。后期会逐步讲解。

   周日，比上班有时候都辛苦~~ 也佩服孩子的精力仿佛永远用不完，这就是童年啊~~~~

转载于:https://my.oschina.net/qfhxj/blog/3083406