客户端调用：
　　// client commits the backlog item to a sprint
　　// by using a domain-specific behavior
　　backlogItem.commitTo(sprint);
　　将第一种是实现方式出现的问题，再和第二种方式进行比较，你会发现，第二种实现方式完全避免掉了，在开始的时候，我们说了，这是一个简单的业务操作描述，没有和领域专家进行深入探讨和交流，如果进行探讨和交流的话，后详细、准确的业务操作描述，应该是这样：
　　允许将每一个待定项提交到冲刺中，只有在一个待定项位于发布计划（Release）中时才能进行提交，如果一个待定项已经提交到了另外一个冲刺中，那么需要先将其回收，提交完成时，通知相关客户方。
　　对于一个详细、准确的业务操作描述，如何进行确定下来，作者进行了如下总结：
　　对于你目前正在工作的业务领域，思考一下模型中的通用术语和业务操作。
　　将术语写在白板上。
　　然后，将项目中所用到的短语也写下来。
　　与真正的领域专家交流一下，看看哪些词汇是可以改善的（记得带上咖啡哦）。
　　我们再来分析一下上面第二种实现方式，希望可以抽离出一些对自己有所帮助的理解，首先，读上面的业务操作描述，然后再和实现代码进行对比，你会发现，它们之间的关系是完全契合的，在上一篇中，我们说过，设计是代码，代码是设计，这种设计是一种通用语言，开发人员和领域专家都能懂的通用语言。
　　在第二种实现的方式中，有两个关键词：commitTo 和 DomainEventPublisher，DomainEventPublisher 是领域事件（Domain Event），这个不要和领域服务（Domain Service）混淆，领域事件我没有使用过，后面再进行学习，你暂时可以把它看作是操作完成后的消息推送者。commitTo 是 BacklogItem 模型中的一个行为，意为提交，你可能会这样想：待定项怎么会有行为呢？它又不是人，我觉得这个很有意思，记得在之前做消息模型设计的时候，一直不确定的一点是发消息这个操作该如何设计？是消息实体的一个行为操作，还是发件人的一个行为操作，又或者是独立出来的一个领域服务（后结果），在这个设计确定的过程中，我们会进行多次讨论，但有一点需要进行明确的是，不只是具有“生命”的实体，才具有行为操作，像消息模型中的操作人，你自然会联想到现实生活中的发件人、收件人等等，认为只有人才会有一些行为操作，但是实际上，在软件系统中，一切的模型都有可能是行为操作，你要摒弃现实生活对你的影响，像上面待定项的提交操作，如果是我设计的话，我会创建一个领域服务进行行为操作，因为，在我的认知中，待定项不具有行为操作，但显然并不是这样，为什么要这样设计？现在还说不出个所以然，以后再慢慢体会。
　　DDD 并不笨重（测试驱动）
　　DDD（领域驱动设计）和 TDD（测试驱动开发），这两者有什么关系？我记得在之前的博文中有提到这一点，我的观点是，DDD 和 TDD 可以之间可以产生一些微妙的化学反应，并不一定要强制的去区分它们之间的关系，比如，如果你的 DDD 项目中，使用了 TDD，并不能说明你的项目不是 DDD 模式了，其实，TDD 可以对 DDD 进行一些补充，或者可以让你的项目，在使用 DDD 的时候，变得如鱼得水。关于它们两者的关系，作者简单说明了一下观点：DDD 也倾向于“测试先行，逐步改进”的设计思路，他们可能有细微的区别，但是基本思路是一样的，DDD 采用的是一种“敏捷的”方式进行软件开发的。
　　可以采取的步骤：
　　编写测试代码以模拟客户代码是如何使用该领域对象的。
　　创建该领域对象以使测试代码能够编译通过。
　　同时对测试和领域对象进行重构，直到测试代码能够正确地模拟客户代码，同时领域对象拥有能够表明业务行为的方法签名。
　　实现领域对象的行为，直到测试通过为止，再对实现代码进行重构。
　　向你的团队成员展示代码，包括领域专家，以保证领域对象能够正确地反映通用语言。
　　具体再说明一下，像上面的待定项提交业务操作，可以完全先写一个测试代码，如下：
　　[test]
　　public void  backlogItemCommit() {
　　...
　　}
　　这个测试代码，其实是领域专家想要的，他不管你是如何具体实现的，他关心的是有没有这个业务操作，以及这个业务操作完成的结果，也是说，测试代码可以很好的反应领域专家所描述的业务操作，那有人可能会说了：你这不是 DDD 了，而是 TDD，表明看上去，好像确实如此，但是不能说写个测试代码是 TDD 开发，而去测试代码并不能反映领域模型，他只是一种辅助方式，你可以把它看作是通用语言的一种，可以帮助你和领域专家进行沟通，也可以加快你的开发速度，又或者可以帮助你完善你的领域模型设计。对应某一业务操作的测试代码，也不是一成不变的，它需要开发人员和领域专家的持续沟通和改进，测试代码是他们进行通用语言的一种表现形势，使用测试代码的好处是，它可以很好的表现业务需求，当然你也可以使用 UI，这些都不过是通用语言的一种罢了。
　　在读《DDD 并不笨重》这一小节点内容的时候，我是很有感触和共鸣的，因为我在之前短消息开发的时候，曾这样搞过，比如，新建一个与 Domain 对应的 Domain.Tests 项目，这个 Domain.Tests 是你和领域专家进行沟通的一个桥梁。
　　对于这个节点内容，可能每个人都有自己的理解，如果大家有不同的想法，欢迎探讨交流，记录到这！