关于ddd:领域驱动设计入门与实践-下

上期对 DDD 进行了简略的介绍，Phone Number 案例也使咱们对 DDD 有了进一步的理解。

通过该案例，咱们理解到 PhoneNumber 蕴含了初始化、校验、属性解决等多种逻辑，而传统的 POJO 类只蕴含其属性的 getter setter 办法。这是 DDD 和传统面向数据开发的重要差别点。

「PhoneNumber- 充血模型」与「POJO 类 - 贫血模型」不难理解，笔者在「畛域驱动设计入门与实际 - 上」中已对其做过介绍。难的是在理论我的项目中，若应用充血模型，如何把握好其强弱水平须要很丰盛的教训。

咱们将 PhoneNumber 这种类型称为 DP- Domain Primitive。类比 Integer、String 在 Java 编程语言中一样，DP 是 DDD 里所有模型、办法、架构的根底。

在 DDD 里，DP 能够说是所有模型、办法、架构的根底，它是在特定畛域，领有精准定义、可自我验证、领有行为的对象，可认为是畛域的最小组成部分。

将隐性概念显性化 /Make Implicit Concepts Expecit
在 Phone Number 这个案例中，若应用 String 类型来定义电话号码，则「归属地编号」、「运营商编号」这些属于电话号码的隐性属性就难以体现进去，咱们通过自定义类型 PhoneNumber，通过赋予它行为来显性化了这两个概念，让代码的业务语义更加明确。

这里咱们通过一个例子来阐明：

假如当初要实现一个性能: 使 A 用户能够领取 x 元给用户 B，可能的实现如下：

public void pay(BigDecimal money, Long recipientId) {bankService.transfer(money, "CNY", recipientId); 
}

如果这个是境内转账，并且境内的货币永远不变，该办法仿佛没啥问题。一旦货币变更或做跨境转账，该办法留有显著的 bug，因为 Money 对应的不肯定是 CNY。

在这个 case 里，当咱们说“领取 x 元”时，除了 x 自身的数字外，还有一个隐含的概念「元」。

在原始的入参中，只用 BigDecimal 的起因是咱们默认 CNY 货币是不变的，是一个隐含的上下文条件。但当咱们写代码时，要 把所有隐性的条件显性化，而后整体组成以后的上下文：做「领取」时，咱们将「领取金额」&「货币品种」作为一个入参输出进来，两者整合成一个残缺而独立的概念：Money。

原有的代码变为：


public class Money {     
    private final BigDecimal amount;     
    private final Currency currency;       
    public Money(BigDecimal amount, Currency currency) {         
        this.amount = amount;         
        this.currency = currency;     
        } 
    }  

    public void pay(Money money, Long recipientId) {bankService.transfer(money, recipientId); 
    }
}

通过将默认货币这个隐性的上下文概念显性化，并且和金额合并为 Money，咱们防止了很多以后看不出来将来可能会暴雷的 bug。

封装多对象行为 /Encapsulate Multi-Object Behavior

将后面的案例降级一下：用户要做跨境转账，从 CNY 到 USD 且汇率随时在稳定。

代码块：



public void pay(Money money, Currency targetCurrency, Long recipientId) {if (money.getCurrency().equals(targetCurrency)) {bankService.transfer(money, recipientId);
    } else {BigDecimal rate = exchangeService.getRate(money.getCurrency(), targetCurrency);
        BigDecimal targetAmount = money.getAmount().multiply(new BigDecimal(rate));
        Money targetMoney = new Money(targetAmount, targetCurrency);
        bankService.transfer(targetMoney, recipientId);
    }
}

这个 case 里

1、targetCurrency 不等于 money Curreny

2、调用一个服务去取汇率，而后做计算

3、用计算后的后果做转账

最大的问题在于 金额的计算被蕴含在领取的服务中，波及多个对象：2 个 Currency，2 个 Money，1 个 BigDecimal。这种波及到多个对象的业务逻辑，咱们要用 DP 包装。

利用 DP 的 封装多对象行为，将转换汇率的性能封装到一个叫做 ExchangeRate 的 DP 里：

ExchangeRate 被定义为汇率对象，通过 对金额计算逻辑 & 各种校验逻辑封装，使原始代码变得简略：

public class ExchangeRate {
    private final BigDecimal rate;
    private final Currency from;
    private final Currency to;
    public ExchangeRate(BigDecimal rate, Currency from, Currency to) {
        this.rate = rate;
        this.from = from;
        this.to = to;
    }
    public Money exchange(Money fromMoney) {notNull(fromMoney);
        isTrue(this.from.equals(fromMoney.getCurrency()));
        BigDecimal targetAmount = fromMoney.getAmount().multiply(rate);
        return new Money(targetAmount, to);
    }
}
public void pay(Money money, Currency targetCurrency, Long recipientId) {ExchangeRate rate = exchangeService.getRate(money.getCurrency(), targetCurrency);
    Money targetMoney = rate.exchange(money);
    bankService.transfer(targetMoney, recipientId);

public class RegistrationServiceImpl implements RegistrationService {
    private final SalesRepMapper salesRepDAO;
    private final UserMapper userDAO;
    private final RewardMapper rewardDAO;
    private final TelecomRealnameService telecomService;
    private final RiskControlService riskControlService;

    public User register(String name, PhoneNumber phone) throws ValidationException {TelecomInfoDTO rnInfoDTO = telecomService.getRealnameInfo(phone.getNumber());
        if (!Objects.equals(name, rnInfoDTO.getName())) {throw new InvalidRelnameException();
        }
        // 计算用户标签
        String label = getLabel(rnInfoDTO);
        // 计算销售组
        String salesRepId = getSalesRepId(phone);
        // 结构 User 对象和 Reward 对象
        String idCard = rnInfoDTO.getIdCard();
        UserDO userDO = new UserDO(idCard, name, phone.getNumber(), label, salesRepId);
        RewardDO rewardDO = new RewardDO(idCard, label);

        // 风控逻辑
        if (!riskControlService.check(idCard, label)) {userDO.setNew(true);
            rewardDO.setAvailable(false);
        } else {userDO.setNew(false);
            rewardDO.setAvailable(true);
        }
        // 长久化数据
        rewardDAO.insert(rewardDO);
        return userDAO.insert(userDO);
    }

    private String getLabel(TelecomInfoDTO telecomInfoDTO) {// TODO}

    private String getSalesRepId(PhoneNumber phone) {SalesRepDO repDO = salesRepDAO.select(phone.getAreaCode(), phone.getOperatorCode());
        if (repDO != null) {return repDO.getRepId();
        }
        return null;
    }
}

惯例逻辑和实现代码。咱们先来给它挑挑刺，再利用畛域驱动设计的思维来重构。发现

问题 1>> 对外部依赖的耦合十分重大

所有不属于以后域内的设施和服务，都可认为是内部依赖。比方：数据库，数据库 Schema，RPC 服务，ORM 框架，中间件….. 并且都是可替换的。咱们要做的是 把由内部依赖变动导致的本人零碎内产生的变动管制在最小范畴。

“由内部依赖变动导致的外部零碎的革新水平，咱们能够了解为一个零碎的可维护性。”

在查看这段代码的可维护性前，咱们先来看看它有哪些内部依赖：

1-1、数据库 Schema

这里的业务代码强依赖数据库 schema，也就是 DO 类。一旦数据表的字段产生变动，DO 类就会随之变动。

但 DO 在这段代码里到处都是，并且将 UserDO 这个对象传递到了办法内部。一旦业务逻辑简单起来、DO 发生变化，这段代码就会面目全非，甚至很可能会毁坏掉原有失常的性能。

1-2、ORM 框架

此代码应用了大家相熟的 MyBatis 框架：应用 Mapper 这种 DAO 对象来构建和执行 SQL。

如果框架自身没有向下兼容、API 产生了变动，零碎要降级框架；或出于对平安问题的思考，零碎要替换整个 ORM 框架，业务代码要进行大量的变动。这是不合理且存在危险的。

1-3、RPC 服务

应用中国电信提供的手机号实名信息查问服务，强依赖在业务逻辑中。一旦中国电信提供的接口入参和返回都产生变动，或者变更服务商，那么业务逻辑代码也要进行相应的批改。说起来简略做起来难，倡议抱有此想法的童鞋趁早放弃，不要给本人找锅背。

剖析了以上三种依赖，大家曾经理解了代码耦合度高的起因。如何革新？

思路：将其革新成面向形象接口的编程。这样，DDD 将会作为一种指导思想辅助咱们设计。

>> 针对数据拜访形象

有两个关键点：

1、DO 是具体实现，不应间接裸露给业务逻辑

2、DAO 作为拜访数据库的具体实现

引入畛域驱动设计中的 Entity 和 Repository。

下层的业务逻辑不须要关怀上层的具体实现。

这里定义了一个 User 类—Entity，一种畛域实体类。User 类中的属性用于形容这个零碎内客户应该含有的信息，应尽量多的应用 DP 来将更多的自检和隐性属性内聚起来。

参照这句话「下层的业务逻辑不须要关怀上层的具体实现」，在定义 User 类的时候，咱们不关怀上层数据库的具体实现、User 对象的存储在哪里，咱们只须要关注如何去形容这个畛域实体。

“有人可能会对 Entity 和 DP 的差异产生纳闷，它们最实质的差别就是主语义上是否领有数据状态。”

Repository 就是数据拜访的形象层。在形象层中，咱们只定义动作。

比方这里的 UserRepository，只定义了 find 和 save 这两个动作，这样在实现类中，咱们就能够依赖数据库拜访相干的具体实现，而后，间接依赖 MyBatis 框架，比拟 Redis Client 等各种数据库操作。

通过对数据拜访层的革新，咱们再来看业务代码，革新前：

// User Entity
public class User extends Entity {
    private UserId userId;
    private PhoneNumber phone;
    private Label label;
    private SalesRepId salesRepId;
    private SalesRepRepository salesRepRepository;

    public User(RealnameInfo info, String name, PhoneNumber phone) {
        // 参数一致性校验，若校验失败，则 check 内抛出异样（DP 的长处）info.check(name);
        initId(info);
        labelledAs(info);
        this.salesRepId = salesRepRepository.ofPhone(phone).getRepId();}

    // 对 this.userId 赋值
    private void initId(RealnameInfo info) {

}

    // 对 this.label 赋值
    private void labelledAs(RealnameInfo info) {// 本地解决逻辑}
}

革新后：


public interface UserRepository {User ofId(UserId id);
    User ofPhone(PhoneNumber phone);
    User save(User user);
}
public class UserRepositoryImpl implements UserRepository {
    private final UserMapper userMapper;
    private final UserConverter userConverter;@Override public User ofId(UserId id) {UserDO userDO = userMapper.selectById(id.value());
        return userConverter.fromDO(userDO);
    }
    @Override 
    public User ofPhone(PhoneNumber phone) {UserDO userDO = userMapper.selectByPhone(phone.getNumber());
        return userConverter.fromDO(userDO);
    }
    @Override 
    public User save(User user) {UserDO userDO = userConverter.toDO(user);
        if (userDO.getId() == null) {userMapper.insert(userDO);
        } else {userMapper.update(userDO);
        }
        return userConverter.fromDO(userDO);
    }
}

>> RPC 调用形象

这里次要有两块改变：

1、应用 RealnameService 接口类代替 TelecomRealnameService 具体实现类— 依赖倒置

2、DP 具体逻辑内聚：应用 RealnameInfo 这个 DP 来代替 TelecomInfoDTO 这个具体实现。这样无论内部服务是参数变动还是替换实现，咱们都将变动范畴管制在了具体实现类和配置文件外部，保障了外围业务逻辑的稳固。

这里还要引入一个概念：

“防腐层（Anticruption Layer）：避免内部零碎的腐烂影响到咱们本人的零碎。这里的 RealnameService 就是咱们的防腐层。”

代码如下：


public class RegistrationServiceImpl implements RegistrationService {
    private final SalesRepMapper salesRepDAO;
    private final UserMapper userDAO;
    private final RewardMapper rewardDAO;
    private final RealnameService realnameService;
    private final RiskControlService riskControlService;

    public User register(String name, PhoneNumber phone) throws ValidationException {RealnameInfo realnameInfo = realnameService.get(phone);
        realnameInfo.check(name);

        // 计算用户标签
        String label = getLabel(rnInfoDTO);
        // 计算销售组
        String salesRepId = getSalesRepId(phone);
        // 结构 User 对象和 Reward 对象
        String idCard = realnameInfo.getIdCard();
        UserDO userDO = new UserDO(idCard, name, phone.getNumber(), label, salesRepId);
        RewardDO rewardDO = new RewardDO(idCard, label);

        // 风控逻辑
        if (!riskControlService.check(idCard, label)) {userDO.setNew(true);
            rewardDO.setAvailable(false);
        } else {userDO.setNew(false);
            rewardDO.setAvailable(true);
        }
        // 长久化数据
        rewardDAO.insert(rewardDO);
        return userDAO.insert(userDO);
    }
}

问题 2 >> 逻辑凌乱

public class RegistrationServiceImpl implements RegistrationService {
    private final UserRepository userRepository;
    private final RewardRepository rewardRepository;
    private final RealnameService realnameService;
    private final RiskControlService riskControlService;

    public User register(String name, PhoneNumber phone) {
        // 查问实名信息
        RealnameInfo realnameInfo = realnameService.get(phone);

        // 构建对象
        User user = new User(realnameInfo, phone);
        Reward reward = new Reward(user);

        // 查看风控
        if (!riskControlService.check(user)) {user.fresh();
            reward.inavailable();}
        // 长久化
        rewardRepository.save(reward);
        return userRepository.save(user);
    }
}

“由外部业务逻辑变动所导致的外部零碎的革新水平，咱们能够广义的了解为零碎的可扩展性”

回到这个例子，注册的内部逻辑曾经进行了肯定水平的解耦，但它仍然不纯正：「奖品对象」和「风控查看」为什么会耦合在注册逻辑中呢？如果，之后的发奖逻辑产生变动，注册办法还要批改吗？

咱们持续思考：

发奖是为了给予新用户一些福利，实质是判断以后用户是否为新用户
在注册这个业务域中，咱们将它的行为形象为「获取用户信息」，「查看并更新用户」，「存储用户信息」，这三个步骤不无不合理之处
在「查看并更新用户」这个逻辑中，存在发奖这种衍生行为与其余可能的行为

理清逻辑后，咱们来看下最终代码：

public interface CheckUserService {void check(User user);
}

public class CheckUserServiceImpl implements CheckUserService {
    private final RiskControlService riskControlService;
    private final RewardRepository rewardRepository;

    @Override public void check(User user) {rewardCheck(user);
        // ...
        // 可能存在的其余逻辑
    }

    private void rewardCheck(User user) {Reward reward = new Reward(user);
        // 查看风控
        if (!riskControlService.check(user)) {user.fresh();
            reward.inavailable();}
        rewardRepository.save(reward);
    }
}

这里须要留神一点：CheckUserService 中进行查看时，可能会扭转 User 对象和 Reward 对象的状态，波及到了多个 Entity 状态扭转的服务，被称为 Domain Service。Domain Service 次要用于封装多 Entity 或跨业务域的逻辑。

依据最终的代码块显示，外围逻辑已清晰，可维护性和可扩展性也大大加强 √

革新前的代码，多个业务逻辑耦合在一起；

革新后的代码，通过对业务逻辑的解耦，测试用例变得更容易保护。

随时间推移，迭代增多，单元测试会破费更少的精力，取得更高的单元测试覆盖率。这就是逻辑内聚 & 解耦给单元测试所带来的益处。

代码革新前：

代码革新后：

>> DP

：形象并封装自检和一些隐性属性的计算逻辑，这些属性是无状态的

>> Entity

：形象并封装单对象有状态的逻辑

>> Domain Service

：形象并封装多对象的有状态逻辑

>> Repository

：形象并封装内部数据拜访逻辑

>> 畛域驱动设计的指导思想

首先对业务问题进行总览
而后对畛域对象 -Entity 进行划分，明确每个畛域对象蕴含的信息和职
责边界，进行跨对象，多对象的逻辑组织 -Domain Service
接着在下层利用中依据业务形容去编排 -Entity & Domain Service
最初做一些基础设施工作：对上层的数据拜访，RPC 调用去做一些具体实现

值得阐明的一点是：在实际工作过程中，DDD 只是对咱们进行一种领导，咱们不用循序渐进，全盘照抄上述这种设计规范，但要遵循 「高内聚低耦合」 的思维， 对边界的划分与管制是畛域驱动设计强调的核心思想。

DDD 的一大益处是它不须要应用某些特定的架构。

因为外围域位于限界上下文中，咱们能够在整个零碎中应用多种格调的架构。有些架构突围着畛域模型，可能全局性地影响零碎; 有些架构满足了某些特定的需要。咱们的指标是 抉择适宜本人的架构和架构模式。

这里咱们简略的介绍两种在 DDD 落地过程中比拟实用的架构格调：

>> Clean Architecture

指标：框架无关、可测试、UI 无关、数据库无关、内部代理无关

COLA Architecture

COLA 代表了简洁的业务思维：

1、COLA 是一种架构思维，是整合了洋葱圈架构、适配器架构、DDD、整洁架构、TMF 等架构思维的一种利用架构；2、COLA 也是框架组件。

利用架构的实质，就是要从繁冗的业务零碎中提炼出共性，找到解决业务问题的最佳模式，为开发人员提供对立的认知，治理凌乱。“从凌乱到有序”= 定义良好的利用构造，提供最佳实际。

畛域驱动设计入门与实际「上 & 下」至此完结。全文作者：nerd4me，一枚优良的程序员小编~

关于ddd:领域驱动设计入门与实践-下

DP（Domain Primtive）

定义 DP：

应用 DP 的三条准则：

案例解说

来说下单元测试

演绎概念

架构

Just My Socks（注册教程内含优惠码）

关于ddd:领域驱动设计入门与实践-下

DP（Domain Primtive）

定义 DP：

应用 DP 的三条准则：

案例解说

来说下单元测试

演绎概念

架构

Just My Socks（注册教程 内含优惠码）

Just My Socks（注册教程内含优惠码）