一 业务设计的起点

功能框架、业务流程、业务操作和信息结构都是针对功能设计展开的，这四个要素是业务设计的核心内容。

推荐的设计方法是：先完成功能框架（用例驱动），再依次完成业务流程、业务操作和信息结构。然而这种设计方法并不绝对，需要具体问题具体分析。

业务设计的起点有三种。

1 用例驱动设计

先梳理业务用例，该方法适合中型系统。

2 流程驱动设计

先梳理业务流程，该方法适合中小型系统。

3 领域驱动设计

先梳理业务的信息结构，该方法适合梳理行业系统。

二 用例驱动设计

先通过划分出目标层用例、步骤层用例等手段，拆分出功能模块，然后再针对每个模块，进一步梳理出业务流程、业务操作和信息结构等内容。

我们定义目标层用例就是在梳理公司的业务，然后再以业务为单元，梳理步骤层用例，随后将步骤层用例合并，从而完成功能单元的划分。

这个思路是层层递进的，非常合理。这样，不可能遗漏业务模块。

三 流程驱动设计

对于一项简单的业务，如用户下单、餐厅排队等业务，可以先梳理业务流程，而不是先梳理业务用例。这样做的好处是，在一开始就能抓住业务主线，并保证业务主线设计的合理性。然后再以此为基础，拆分出目标用例（业务目标）、业务操作和信息结构等。

例如，餐厅排队系统就是先处理出排队流程，然后又拆解出领号、叫号、领位和查号等业务目标，最后再梳理桌台和订单的信息结构。

该方法的好处是，梳理业务的过程很自然。通过梳理流程就能很自然地梳理出业务逻辑。如果一上来就问有哪些业务模块，则对方不一定能说出。

四 领域驱动设计

该方法可进行静态的业务设计和软件架构，其核心思想是先梳理信息结构（类图）和业务规则，再梳理业务的用例、流程和操作等内容。

1 领域驱动设计的含义

我们说张三是通信领域的专家，李四是导弹领域的专家，他们都拥有各自领域的知识。所谓领域驱动设计，就是以梳理行业知识为出发点，进而构建出完整的业务。这些行业知识主要是信息结构、行业规则等内容。反而业务流程、业务目标等变成次要信息了。领域内容的梳理决定了软件的体系架构，而业务流程、业务目标等，不过是这个基础上的业务实现而已。

2 领域驱动设计的作用

领域驱动设计要先梳理信息结构，这特别适合在复杂系统中，尤其适合用在 Saas 软件中，如行业用的财务系统、人力服务系统、餐饮系统等。该方法可确保软件具有较强的可扩展性，从而适应不同企业的不同需求，避免软件的重复开发和反复修改。

案例一：用户和组织结构

D 公司是人力外包公司，早期采用敏捷开发，并不重视信息结构的梳理。但是随着业务的发展，其业务越来越多，软件无法支撑未来业务的发展。比如，几个系统的用户信息并不一致，有的以手机号区别用户，有的以用户 ID 区别用户。当需要将不同账号信息汇总展示时，该公司就面临困难。

另外，该公司的订单和服务模式也很复杂。该公司可以和其个集团公司签订合同，并由集团公司支付服务款项，但是落实的服务对象可能是集团公司下属事业部或分公司，也可能是一个完全独立的公司。D 公司需要对各个组织单独服务，但集团公司还要求能看到各个组织的信息，或进行一定的权限设置。然而，该业务开始没有考虑到这些，导致设计的数据库需要大改。

案例二：收费和业务需求

R 公司是给餐饮、零售企业做软件的公司，提供的业务众多，面对的公司类型也众多。比如，运营人员提出几个模块可单独收费，也可组合收费，并且有预付费等多种收费模式，但是该系统不具有可扩展性。再如，某集团公司要求把集团公司下的某品牌单独拆出，进行独立运营和核算，但该系统无法满足此需求。

造成以上问题的原因，一方面是，研发人员在搭建数据库的时候没考虑其扩展性，另一方面是，产品经理没说清楚需求，即没说清楚业务模型、权限要求、服务要求等。如果产品经理想写出让研发人员不返工的产品需求文档，则必须保证信息结构设计正确、有足够的可扩展性、能灵活应对业务需求，这些都可用类图进行梳理。

综上所述，领域驱动设计特别适合应对复杂行业，尤其是灵活多变的行业需求。而在开发此类软件的公司，通常拥有深厚的行业背景，并能引领行业管理的发展。在这里，软件公司不仅是软件的制造者，也是行业管理的引领者。

五 小结

如果行业业务目标多，就从用例驱动设计开始，用例驱动设计通常适合中型系统。

如果业务较为简单，就从流程驱动设计开始，流程驱动设计通常适合中小系统。

如果业务信息结构复杂，需要灵活扩展，就从领域驱动设计开始，领域驱动设计通常适合行业系统。

当不好确定哪种方法优时，三种方法可都做一下，看看哪种方法更容易理清业务，就从哪种方法开始。