领域驱动设计实践——流水号生成器（下）

领域驱动设计实践——流水号生成器（下）2011-12-12 博客园保权0. 上篇回顾

在上篇中我们使用测试驱动开发方法（Test-Driven Development）实现了一个简单的流水号生成器，并获得了一个初步的软件模型：

图1 编号生成器模型（V1）

熟悉设计模式的朋友们一眼就会看出来，这里运用了组合模式（Composite Pattern），把每个子流水号当做一个流水号来处理。虽然这个模型还能工作，但是我们仔细分析一下就会有很多疑问：

ISerialNumberGenerator接口有什么用？为什么不直接使用抽象类（TSerialNumberGeneratorBase）？

客户需要验证流水号吗？即使需要，Validate函数应该返回Boolean吗？

调用NextSerialNumber函数时需要传入一个流水号，是不是意味着其调用者需要知道当前的流水号？对于Generator来说这样合适吗？

既然TConstantCodeSerialNumberGenerator表示固定代码，那调用NextSerialNumber方法是不是很奇怪？

如果考虑在流水号中加入日期的话，这个模型需要怎么修改？

…

除了有这些疑问以外，恐怕这个模型存在最大的问题在于：它看上去更像是一种技术模型——虽然能勉强工作，但是没有表现任何领域知识。

现在，我们该停下来，回到起点，重新思考一下：

What"s the Problem？

1. 领域知识

我们要解决的问题其实很简单——就是要获取一个可用的编号（Number）。编号一般是有几部分（Part）组成的。比如某张入库单的编号”RK200901160001”就包含下面3个部分：

代码：“RK”

日期：“20090116”

流水号：“0001”