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的定义，有具体的标识）

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