DDD - 概述 - 聚合 - 限界上下文 (四)

最重要的一句话

DDD的全部有相关理论中，只有一句是相当重要的，可是也是最容易被忽略和最难作到的，抛弃传统的设计方式（思路）的思想，这句话起了决定性的做用，可是99%的人都忽略了或者在开始没法正视或理解。

为何说这句话是最重要的一句话，由于他是设计真正转变的出发点。

基于具体的语义环境

首先，DDD的重点在于领域这个东西，领域的肯定必需要基于必定的环境的，简单理解就是 必须同时具有主谓宾，好比：小明关爱小花；对于这句话的理解其实存在歧义，若是没有具体的语义环境下可能有如下两种理解方式：

　　1）.小明 关爱（关系爱护）小花

　　2）.小明关 爱 小花

　　。。。其余你可能想到的语义。若是不肯定具体的语义环境 那么就没法肯定限界上下文，间接的就是没法肯定聚合如何建立，由于没有这个具体的语义环境就没法肯定的限界上下文就没法决定如何肯定聚合跟，谁是主（聚合跟）谁是次（实体），谁又是用做点缀、修饰用的（ValueObject）.

示例参考

再换一个示例：组织架构，这个几乎全部的管理系统可能都会涉及，尤为是OA之类的管理系统

　　不合理的方式：按照以往的凡是去设就是，根据组织架构的相关业务（逻辑），你确定噼里啪啦的设计出来了几张表，Role,RoleClaim,User,UserClaim,UserDetail,LoginLog,Department,...而后就相关也业务开发了，，，可是，你以为这个和DDD有啥关系，没一毛钱关系，你仍是依旧的沉浸在以往的条件反应式的思想中，长期以往的思惟方式已经让你机械化的知道须要这么作，那么若是不从DDD的角度，你这么作是彻底Oj8K的，是的，你作的彻底没问题。可是从DDD角度是彻底大错特错的， 若是你有读过 实现领域驱动设计 ，你可能会记得还有一句话就是 以用户（使用者）的思想去思考，而不是继续使用开发者个思惟角度去思考，也是由于这个缘由。

　　正确的作法是：首先肯定你当前要实现的业务功能，以此肯定边界，好比，咱们打算开发的内容是，用户角色管理，那么这里就突出了两个对象一个动做，1）用户；2）角色） 3）和一个动做管理，这就肯定了咱们的上下文对象 能够肯定为 UserRoleDbContext（通常的命名会直接明了的凸显出具体的语义含义），

那么这时候猜到了思考咱们的聚合跟 Entity 以及ValueObject的设计。因此，这里咱们的聚合对象就是User,由于一个用户能够对应多个role,同时role这个对象若是在没有具体的用户的状况下 他的存在也没有任何意义,可是多个用户可能有相同的角色，因此role能够肯定为entity（DDD中entity的定义，有具体的标识）

以上是本人在设计在开发中的总结，若是您以为不合理请指教。谢谢。