领域驱动设计第一篇-DP主题

一：领域驱动设计概述

领域驱动设计。Domain-Driven Design 可以理解为基于领域的工程设计。

1：什么是领域？

初步理解领域：业务问题的范畴。

领域可大可小，对应着大小业务问题的边界。业务上要做的几个事，抽象拆分成多个内聚的领域 

2：通过一个样例感受DDD

(一)：样例说明

地推员录入客户名称和手机号，根据手机号分配归属地和运营商，根据客户群体进行分组，分配给相应的销售组跟进后续业务。

需要提供一个注册服务。入参是：

客户和手机号  ==》查询运营商 ==》获取分组编号 ==》构建客户对象 ==》存入数据库

(二)：找找问题

1：register接口语义有歧义、拓展性差，有歧义。

2：参数校验逻辑逻辑需要复用、内聚。不应该散落在每个参数方法内部。

3：参数校验异常和业务逻辑异常应该解耦。

        接口语义有歧义、拓展性差的原因就是因为接口的参数使用了基本类型参数，并且参数的个数是固定的。这个最好使用自定义的类型去代替。自定义类型应该包含属性+自校验逻辑。

业务逻辑的纯粹性。Register方法是一个注册服务，注册方法就是拿到客户信息 ==> 进行保存。所以、根据手机号归属编号和运行编号通过编号找到区域内的销售不应该属于这块内容。

知识补充：

什么叫胶水逻辑：胶水逻辑就是通过原有的业务参数，进行缝缝补补的操作，给后边的方法用，的操作就叫胶水逻辑。

如何改造胶水逻辑呢？要不直接给findRep方法自定义对象，如果是调用比人的接口，那么胶水操作可以内聚到PhoneNumber对象中，然后在findRep

如果一个业务方法内包含各种胶水操作，然后胶水操作又依赖其他的胶水操作，那么后续只能小心的屎山上雕花了。 

单元测试可行性。

通过上述的操作， 印象最深刻的应该就是DP（Domain Primitive）自定义对象了。传统的POJO中，类中只有属性和getset、但是DDD中的DP中不仅仅有属性，还有与属性相关的职责，这是典型的充血模型、前者是贫血模型。

(三)：DP的定义

在DDD中，DP可以是说是一切模型、方法、架构的基础。他是在特定领域、拥有精准定义、可以自我验证、拥有行为的对象。可以认为是领域的最小组成部分。

(四)：DP的三原则

让隐形的概念显性化

归属地编号、运营商编号属于电话号码的隐藏属性。使用String属性定义电话号码，这些属性很难展示出来，基于DP可以让隐形的上下文显性化。

让隐形的上下文显性化

封装多对象行为。

封装多对象行为就是一个DP里边可以放其他的DP。