业务对象的抽象

通过对业务问题的子域划分，我们找到了一些关键的业务对象。在开始进行抽象前一个必须的步骤就是“讲故事”！

讲什么故事呢？关于这个子域解决的业务问题或者提供的业务能力的故事。既然是故事，就必须有清晰的业务场景和业务对象之间的交互。这件事情看起来是如此自然和简单，然则一个团队里能够站起来有条不紊陈述清楚的却没有几人。读到这里的读者不妨停下来试试，你是否能够把现在你所做的业务在两三分钟内场景化地描述出来？

这么做显然目的是让我们能够比较完整地思考我们所要提炼和抽象的业务对象有哪些。只有当我们能够“讲”清楚业务场景的时候，才应该开始抽象的步骤。对于一个业务对象，我们常见的抽象可以是“实体”（Entity）和“值对象”（Value Object）。

这两个抽象方式在定义上的区别是，实体需要给予一个唯一标识，而值对象不需要（可以通过属性集合标识）。当然另外一个经常引用的区别是，实体应该是有一个连续的生命周期的，比如我们在一个订单跟踪领域里抽象订单为一个实体，那么每个订单应该有一个唯一识别号，订单也应该有从下单创建到最后交货完成的生命周期。

显然，如果不增加其它约束条件，值对象的抽象是没有意义的，都用实体不就行了？但如果我们稍微思考一下一个实体的管理成本，比如需要保证生命周期中实体状态的一致性，那么我们就会发现值对象变得很简单很可爱。当一个对象在我们（抽象）的世界里不能改变的时候，一切都变得简单了，这个对象被创建后只能被引用，当没有引用时我们可以把它交给垃圾回收自动处理。

随着高并发、分布式系统的普及，实际上我们在对业务对象抽象的第一步思考是能否用值对象。如果大家实现的技术架构采用函数范式的语言（类似Closure），那么首先考虑值对象抽象可能就是一个建模原则了。

对象抽象初步完成后，一定要再重复一次之前的故事来审视一下我们的建模。经历这个抽象过程后，参与讨论的每个人都应该发现自己更清晰业务的需求和需要提供的能力了。