#原创分享# DDD领域建模---老调新弹之【实体】

    在熟悉【值对象】之后，依旧由必要重温一下OOP思想下的【实体】，在这里之所以定义概念为【实体】，而不是对象，没有什么太大的区别，更多的可能是习惯于DDD的思维模式，在学习DDD思想体系中，更容易把对象的建模称之为【实体】，在这里【实体】的概念无对象无所差别，大致如下：（下面的一段文章都是Copy 而来的）：

【实体】（或者对象）有以下特点：

• 对象具有属性和行为。
• 对象具有变化的状态。
• 对象具有唯一性。
• 对象都是某个类别的实例。
•  一切皆为对象，真实世界中的所有事物都可以视为对象。

 同时，【实体】还具备对象该有的一些编程特性：继承性、封装性与多态性   上述的这些知识点都是OOP的基础中的基础，需要大家认真的体会与实践。我从学习到体会到这些字面意思背后的含义，用了很多年啊。终于有点自己的新的与体会了，在这里着重强调如下几点：

  1、【实体】的唯一性标识：唯一的身份标识与可变性让我们区别于上个章节提到的【值对象】，在【实体】开始设计的过程中，特别需要关注实体唯一性标识，而不是其他的属性与行为方法，切记，到目前未知，事物的唯一标识依旧困扰着我，基本无解状态。例如 ：基于数据库的自增长主键？ 基于UUID？基于用户输入等，不同的策略都带来不同的副作用~~ 依旧很纠结

 2、挖掘【实体】的关键行为，具体体现为事物本身所对外暴露的方法，概括起来很简单，实际操作缺比较难，因为很多情况下，大家都把操作归结为CRUD，而非业务语言。我们需要提供 一个由意图的展示接口或者方法，用于定义【实体】的具体行为，减少一些CRUD命名的操作。 另外一点就是尽量让每个【实体】的行为保持其单纯性，每个行为都有明确且确定的业务含义，减少一些 二义性方法的定义。例如 update 方法，应该明确的定义为updateXXXX方法。例如：我们在设计登陆账户的时候，由用户修改密码的需求，基于Account实体，我们应当定义这样的予以清晰的方法：Account .changePassword(String oldpwd,String newpwd); 当然密码本身的加密策略不在这里讨论，他应当在服务层中讨论。 账户自身要修改自身的密码，与 让别人重置密码是有区别的，重制密码应该定义为： Manager.resetPassowrd(Account user,String newpwd);

 3、充分利用构造函数初始化，而非使用一系列的setter方法来完成类的初始化【实体】,构造函数现在已经完全被大家所忽略了，我觉得都是Hibernate惹的祸。

4、hasCode 与 equels  方法的重载，【实体】是如何判断其相等。 两个【实体】是否一致，由多种判断标准，实际业务中，关注点不同，判断的方法也不尽一致....这一点要注意，例如上文的   用户修改密码 场景，我们判断的标准仅局限于  两个表示同一事物的 密码是否相等，而其他属性则是完全被忽视的，具体要在实际的编码过程中体会。

5、【实体】属性的逻辑验证，对于构成【实体】的属性，都有它的取值范围，而针对取值范围的验证，则都需要在构造函数中完成，一旦构建完成，那么他的所有属性都符合该【实体】的业务逻辑。编程技巧可以多样化，例如  创建私有的setter方法，在构造函数中调用该setter初始化。在setter方法中定义该属性的取值范围校验。

6、【实体】的两个构造函数：这算是我个人的编程习惯，一个是暴露给外部创建使用，一个是暴露给DB层还原【实体】使用，后者仅局限于DAO层使用，所以方法不可能是 public 属性。另外最好额外增加一个 标识，表明【实体】的创建来源，是被用户创建的临时实体，还是从DAO层还原的实体，在一些场合下会显得很有业务意义。

7、【实体】整个的校验，这个可能依赖与当时所在的环境，例如一些属性的唯一惯，这个需要Dao层协助一起完成的逻辑校验，但是不可或缺，尽管在DB层通过唯一的索引也可实现该功能，但我跟推荐大家在程序中完成该逻辑的校验等，【持久化】数据在这里要弱化，数据库在DDD角度来看，仅仅是存储【实体】或者其他的一种 载体。

       至于其他的OOP的原则，例如 里氏代换原则 等就不再描述了~~这些都是OOP的基础了~~~，这边文章所描述的都是基于他们的基础之上的更多的一些细节与完善，期间，很多是我在编程过程中的一些个人习惯与爱好。

        这篇文章 断断续续的，续写了好多次才写完，说明在OOP这块，我自己也卡壳比较严重，有空要继续重塑一下OOP建模以及在DDD下【实体】的相关特性，后期如果先到其他的方面，在补充进来~~~~~~

 

 

 

 

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