01缘起

在我写《解构领域驱动设计》一书时，真正确定“业务服务”名称，是在完成初次审稿的时候了。最初的名称叫“业务活动”，它是问题空间进行需求分析的基本业务单元。到了解空间，在进行领域设计建模时，我将其“改头换面”，称其为“服务场景”，由此有了“场景驱动设计”。

我认为这样的改头换面，会因为累积太多概念而让人茫然不知所措，在一次出行途中，我在脑海中揣摩这一套方法，灵光一闪，觉得可以将其统一命名为“业务服务”，并将其贯穿问题空间和解空间始终，形成一个完全围绕“业务服务”的整套设计过程，姑且可以称之为“服务驱动设计”。

编写业务服务时，需要遵循统一语言，并由领域专家和开发团队共同编写和维护，业务服务规约包含的就是领域知识，如此一来，所谓的“服务驱动设计”就完全属于领域驱动设计的范畴。

02并非创新

之所以我要提出这个概念，并非要做什么“创新”，实则因为在Eric Evans的书中，压根就没有给出一个概念，以统一的格式体现领域知识。没有这样的概念，何谈领域驱动设计呢？
自然，需求的呈现方式业内已有成熟方案，例如用例，例如用户故事，例如特征，例如业务行为，例如测试用例。除了用户故事之外，这些呈现需求的方式实际上已经形成了对应的设计方案，即用例驱动设计（UDD）、特征驱动设计（FDD）、行为驱动设计（BDD）、测试驱动开发（TDD）。
它们与领域驱动设计一样，都是XDD家族的一员，但整个设计过程可以说是迥然不同（或许某些设计思想、设计理念与原则是相同的），各自形成了自己的一套设计方法体系与设计过程。
如果不为领域知识规定一套固定的形式，说起来，领域驱动设计就更能兼容并包，用例、用户故事、特征、业务行为、测试用例似乎都可以放到DDD这个“筐”中来。所以，这并非我引入“业务服务”的根本原因。我会在这个系列文章中细细道来。

03这是一个系列

没错，这是一个系列文章。我期望利用一个相对完整的案例阐述整个服务驱动设计的过程。
服务驱动设计过程差不多是《解构领域驱动设计》中DDD参考过程模型的一个缩减版，全程围绕“业务服务”开展需求的分析、架构设计与建模。整体过程如下图所示：

以业务服务为起点，通过业务服务识别限界上下文，同时，对业务服务进行细化，编写包含领域知识的业务服务规约。这属于领域驱动设计统一过程的全局分析阶段。
进入架构映射阶段。可以通过业务服务识别限界上下文，然后在限界上下文的基础上，通过业务服务规约绘制服务序列图，得到各个限界上下文的服务契约，包括服务契约的定义，确定上下文映射关系。由此进入领域建模阶段。
建模的起点仍然是业务服务。业务服务规约遵循了统一语言的原则表现领域知识，由此可以识别出领域概念，建立领域分析模型。在领域分析模型的基础上，通过识别实体、值对象，明确实体之间的关系，就可以设计出聚合，获得静态的领域设计模型。
服务契约属于菱形对称架构的北向网关，由菱形对称架构可以确定整个限界上下文的角色构造型，然后在静态领域设计模型和角色构造型的基础上绘制服务契约的序列图，获得以伪代码形式表现的序列图脚本。
最后，就可以根据业务服务规约中的验收标准识别出测试用例，开展测试驱动开发，逐步获得由产品代码和测试代码组成的领域实现模型。
这就是服务驱动设计的全过程！

04技术部落案例

一个理想的DDD学习案例，需要具备以下特点：

• 没有业务知识的门槛，因为需要面对不同领域的读者
• 系统复杂度不能太低，太低，就体现不出DDD的价值
• 系统复杂度不能太高，太高，就很难通过系列文章完整体现

我从Simon Brown的书《程序员必读之软件架构》(Software Architecture for Developers)中找到了一个符合以上条件的案例，即“技术部落”，有兴趣的同学可以在GitHub(或者Gitee)上搜索“techtribesje”，获得该案例的源代码。
简而言之，技术部落就是为IT人员打造的一个社交平台。
为了增加一定的复杂度，我对Simon的案例进行了调整。为方便理解，我为一些需求功能给出了模板产品作为参考。需求包括：

• 系统支持个人用户和企业用户
• 每个用户都可以创建自己的部落，每个用户都可以申请称为部落的会员（类似知识星球）
• 部落会员可以在部落中发表或分享文章
• 部落会员可以在部落中提出问题或回答问题（类似知乎）
• 部落会员可以在部落中组织线下活动（类似豆瓣）
• 部落会员可以在部落中组织直播活动（类似抖音）
• 个人用户可以发布求职信息，企业用户可以发布招聘信息（类似51Job）

我承认这是一个大杂烩的杰出经典作品。但当我给出每个需求功能对应的Model产品时，大家是否有秒懂的感觉呢？显然，分析这样的项目，不会有业务的知识门槛。
Simon的案例给了我启发，但本系列文章却不会使用Simon书中的任何内容，也不会用到他提供的案例代码。我仅仅是披了“技术部落”这个外壳，内在做的是服务驱动设计的工作。
因为不是写书，所以本系列文章的内容会显得更为随意，其中，还会引入工作坊的部分成果，通过点评演练成果帮助读者更好的理解我所要讲述的知识点。
至于要写多少篇文章，什么时间能够全部写完？——谁知道呢？我只能承诺，这个系列文章一定能够写完。就这样了，洗洗睡吧！