IDDD 实现领域驱动设计-一个简单业务用例的回顾和理解-阿里云开发者社区

开发者社区> 开发与运维> 正文

IDDD 实现领域驱动设计-一个简单业务用例的回顾和理解

简介:

Domain Experts-领域专家

这节点内容是昨天的一个讨论引发的思考。

什么是领域专家?简单来说,就是对某一业务领域精通的人,这个人可以是医生、学者、作家、艺术家等等,不管是什么职业,什么身份,只要对某一业务领域精通,都可以称之为领域专家。这样说可能会让你感到茫然,我举一个例子,比如你们软件公司要开发一套快递行业的业务系统,然后你需要到实际企业去了解业务流程等等,暂时把这个实际企业想象成很小(非三通一达),那么你到这个企业第一时间找的是谁呢?准确来说,应该是这个公司的 CEO,因为只有他最最了解他们公司的业务,毕竟是他创办的公司,CEO 不了解,还有谁还了解呢,那么,这个公司的 CEO 就可以看作是领域专家。CEO 一般是蛮忙的,有很多的琐事需要处理,所以,在你和他聊天了解业务的时候,最好是先准备一杯咖啡!

当我们开发人员自己开发一套系统的时候,在开发团队之间,领域专家的概念就慢慢淡化了,为什么?因为领域专家变成了我们开发人员自己,自己给自己布置业务,然后自己再去完成,这样虽然很高效,因为没有非技术人员的参与沟通,但是这样就会造成一些问题,比如,开发人员在思考业务流程的时候,会按照开发人员的思路去理解,比如,一个简单的业务操作描述,开发人员会首先想到的什么呢?一个表单和一个 Button,然后就是对这个表单和 Button 操作的具体实现了,等项目开发完成后,需要交付真正的客户去检验,客户让你演示这个业务操作,然后你就开始对表单和 Button 进行操作了,说这就是业务操作,但是,客户突然来一句:我们不要表单和 Button 操作,UI 需要重新搞,这时候,你就傻眼了,因为你所有的内容代码实现都是围绕着表单和 Button。说了这么多,到底是什么意思呢?在这个过程中,你并不了解这个业务操作背后所蕴含的业务含义,首先,业务不是 UI,UI 只不过是业务的一部分体现,有时候,业务仅仅只是领域专家的一段描述,开发人员需要对这个业务描述,进行一点一点的抽离,把术语和操作分离开,然后再和领域专家进行深入的探讨,这个过程可能会花很多的时间,但是是非常重要的,做完这些前期工作,你再去实现业务操作,你会发现,不管 UI 如何变化,这个业务操作的本质是没有发生变化的,也就是说你的内部代码不需要进行修改,UI 修改那就交给前端工程师就可以了,和你没太大关系。总的来说,就是不要让 UI 驱动你开发,而是让业务驱动你开发。

对上面的内容,我还需要补充一点,就是开发人员需要领域专家,开发人员和领域专家的身份最好不要重叠,要不然会造成一系列的问题,还有就是,在整个领域驱动设计的过程中,开发人员和领域专家的地位是相同的,不要有任何的轻视心态,要用平等的心态去沟通交流。领域专家的概念,让我想到一个很相似的事,就是苹果在开发一个产品的时候,会请很多的非技术人员参与,这些人遍布各行各业,医生、学者、作家、艺术家等等,苹果为什么要请他们,就是想让他们参与产品的设计,因为他们就是产品的使用者,他们提出的想法就是实实在在的用户建议,这个产品开发过程,其实就可以看作是领域(产品)驱动设计,这些参与产品设计的非技术人员,就可以看作是领域(产品)专家。

一个简单业务用例的回顾和理解

这个简单业务用例描述是这样的:一个 Scrum 模型,我们需要将一个待定项(Backlog Item)提交到冲刺(Sprint)中去。

这是最简答的描述,没有经过和领域专家进行深入沟通的,Scrum 是敏捷开发中的概念,这个就不说明了,因为我也不懂,你只需要知道上面的操作就可以了,一般的实现方式(属性访问):

public class BacklogItem extends Entity {
    private SprintId sprintId;
    private BacklogItemStatusType status;
    ...
    public void setSprintId(SprintId sprintId) {
        this.sprintId = sprintId;
    }

    public void setStatus(BacklogItemStatusType status) {
        this.status = status;
    }
    ...
}

客户端调用:

// client commits the backlog item to a sprint
// by setting its sprintId and status

backlogItem.setSprintId(sprintId);
backlogItem.setStatus(BacklogItemStatusType.COMMITTED);

上面的实现过程,完全和上一篇 saveCustomer 的实现方式一样,这样做没什么不可以,因为我也这样干过,只是你会总感觉有哪些不对劲的地方,首先,在实现待定项提交到冲刺这个操作的时候,你首先查看的是 BacklogItem 中的属性,然后就是对这个属性进行设置,在这个过程中,你忘记了你实现的是一个行为操作,而不是一个属性赋值操作,这样说来,是不是有点脚本模式开发,还有就是如果客户端第二个属性赋值 setStatus 出现了错误,因为第一个 setSprintId 已经成功完成,这个该怎么进行处理,即使有处理,这个操作也完全放在了客户端去完成,像 saveCustomer 一样,如果再增加一个属性赋值操作,你的实现将越改越乱,最重要的是,再客户端暴露了 BacklogItem 模型的具体结构,这个应该是要避免的。

我们再来看另一种实现方式:

public class BacklogItem extends Entity {
    private SprintId sprintId;
    private BacklogItemStatusType status;
    ...

    public void commitTo(Sprint aSprint) {
        if (!this.isScheduledForRelease()) {
            throw new IllegalStateException(
                "Must be scheduled for release to commit to sprint.");
        }
        
        if (this.isCommittedToSprint()) {
            if (!aSprint.sprintId().equals(this.sprintId())) {
                this.uncommitFromSprint();
            }
        }
        
        this.elevateStatusWith(BacklogItemStatusType.COMMITTED);
        
        this.setSprintId(aSprint.sprintId());
        
        DomainEventPublisher
            .instance()
            .publish(new BacklogItemCommitted(
                    this.tenant(),
                    this.backlogItemId(),
                    this.sprintId()));
    }
    ...
}

客户端调用:

// client commits the backlog item to a sprint
// by using a domain-specific behavior

backlogItem.commitTo(sprint);

将第一种是实现方式出现的问题,再和第二种方式进行比较,你会发现,第二种实现方式完全避免掉了,在开始的时候,我们说了,这是一个最简单的业务操作描述,没有和领域专家进行深入探讨和交流,如果进行探讨和交流的话,最后详细、准确的业务操作描述,应该是这样:

  • 允许将每一个待定项提交到冲刺中,只有在一个待定项位于发布计划(Release)中时才能进行提交,如果一个待定项已经提交到了另外一个冲刺中,那么需要先将其回收,提交完成时,通知相关客户方。

对于一个详细、准确的业务操作描述,如何进行确定下来,作者进行了如下总结:

  1. 对于你目前正在工作的业务领域,思考一下模型中的通用术语和业务操作。
  2. 将术语写在白板上。
  3. 然后,将项目中所用到的短语也写下来。
  4. 与真正的领域专家交流一下,看看哪些词汇是可以改善的(记得带上咖啡哦)。

我们再来分析一下上面第二种实现方式,希望可以抽离出一些对自己有所帮助的理解,首先,读上面的业务操作描述,然后再和实现代码进行对比,你会发现,它们之间的关系是完全契合的,在上一篇中,我们说过,设计就是代码,代码就是设计,这种设计就是一种通用语言,开发人员和领域专家都能懂的通用语言。

在第二种实现的方式中,有两个关键词:commitTo 和 DomainEventPublisher,DomainEventPublisher 是领域事件(Domain Event),这个不要和领域服务(Domain Service)混淆,领域事件我没有使用过,后面再进行学习,你暂时可以把它看作是操作完成后的消息推送者。commitTo 是 BacklogItem 模型中的一个行为,意为提交,你可能会这样想:待定项怎么会有行为呢?它又不是人,我觉得这个很有意思,记得在之前做消息模型设计的时候,一直不确定的一点是发消息这个操作该如何设计?是消息实体的一个行为操作,还是发件人的一个行为操作,又或者是独立出来的一个领域服务(最后结果),在这个设计确定的过程中,我们会进行多次讨论,但有一点需要进行明确的是,不只是具有“生命”的实体,才具有行为操作,就像消息模型中的操作人,你自然会联想到现实生活中的发件人、收件人等等,认为只有人才会有一些行为操作,但是实际上,在软件系统中,一切的模型都有可能是行为操作,你要摒弃现实生活对你的影响,就像上面待定项的提交操作,如果是我设计的话,我会创建一个领域服务进行行为操作,因为,在我的认知中,待定项不具有行为操作,但显然并不是这样,为什么要这样设计?现在还说不出个所以然,以后再慢慢体会。

DDD 并不笨重(测试驱动)

DDD(领域驱动设计)和 TDD(测试驱动开发),这两者有什么关系?我记得在之前的博文中有提到这一点,我的观点是,DDD 和 TDD 可以之间可以产生一些微妙的化学反应,并不一定要强制的去区分它们之间的关系,比如,如果你的 DDD 项目中,使用了 TDD,并不能说明你的项目就不是 DDD 模式了,其实,TDD 可以对 DDD 进行一些补充,或者可以让你的项目,在使用 DDD 的时候,变得如鱼得水。关于它们两者的关系,作者简单说明了一下观点:DDD 也倾向于“测试先行,逐步改进”的设计思路,他们可能有细微的区别,但是基本思路是一样的,DDD 采用的是一种“敏捷的”方式进行软件开发的。

可以采取的步骤:

  1. 编写测试代码以模拟客户代码是如何使用该领域对象的。
  2. 创建该领域对象以使测试代码能够编译通过。
  3. 同时对测试和领域对象进行重构,直到测试代码能够正确地模拟客户代码,同时领域对象拥有能够表明业务行为的方法签名。
  4. 实现领域对象的行为,直到测试通过为止,再对实现代码进行重构。
  5. 向你的团队成员展示代码,包括领域专家,以保证领域对象能够正确地反映通用语言。

具体再说明一下,像上面的待定项提交业务操作,可以完全先写一个测试代码,如下:

[test]
public void  backlogItemCommit() {
    ...
}

这个测试代码,其实就是领域专家想要的,他不管你是如何具体实现的,他关心的是有没有这个业务操作,以及这个业务操作完成的结果,也就是说,测试代码可以很好的反应领域专家所描述的业务操作,那有人可能就会说了:你这就不是 DDD 了,而是 TDD,表明看上去,好像确实如此,但是不能说写个测试代码就是 TDD 开发,而去测试代码并不能反映领域模型,他只是一种辅助方式,你可以把它看作是通用语言的一种,可以帮助你和领域专家进行沟通,也可以加快你的开发速度,又或者可以帮助你完善你的领域模型设计。对应某一业务操作的测试代码,也不是一成不变的,它需要开发人员和领域专家的持续沟通和改进,测试代码就是他们进行通用语言的一种表现形势,使用测试代码的好处就是,它可以很好的表现业务需求,当然你也可以使用 UI,这些都不过是通用语言的一种罢了。

在读《DDD 并不笨重》这一小节点内容的时候,我是很有感触和共鸣的,因为我在之前短消息开发的时候,就曾这样搞过,比如,新建一个与 Domain 对应的 Domain.Tests 项目,这个 Domain.Tests 就是你和领域专家进行沟通的一个桥梁。

对于这个节点内容,可能每个人都有自己的理解,如果大家有不同的想法,欢迎探讨交流,就记录到这!



本文转自田园里的蟋蟀博客园博客,原文链接:http://www.cnblogs.com/xishuai/p/iddd-domain-experts-and-specific-case-and-tdd.html,如需转载请自行联系原作者

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
开发与运维
使用钉钉扫一扫加入圈子
+ 订阅

集结各类场景实战经验,助你开发运维畅行无忧

其他文章