业务分析
我个人的习惯是在进行业务分析时走这样的路线图。
业务说明
要搞清楚DDD，只需要一个实际且足够具体的案例就行了，所以这里就以一个曾经主导开发过的《特色农产品电商平台》为例来说明。
这个电商平台提供的产品和服务非常繁多，但个人认为比较有特色的当属认养业务。
后续所有与DDD相关的内容都会围绕
认养来展开。因为牵涉面较广，即使是
认养也涉及到加盟商、团长和推手等诸多角色的参与，所以会尽量排除这些干扰，只把注意力放在平台与用户之间的业务关系上。
业务描述
某农场拥有一片山地、草场，并且有一批农牧产品即将到达可面市销售阶段，该农场希望通过互联网的方式扩大销售面，提升销售额，为消费者直供物美价廉的农牧产品。
农场管理者希望以
认养方式进行销售，通过自研电商平台发布各种活动。农场也欢迎有合作意向的中小商家入驻，共同为用户提供优质的产品和服务。个人用户也可以注册成为社区团购的团长，参与平台的营销活动，赚取佣金。也可以成为分销推手，赚取抽成。
用户通过小程序观看农牧产品相关视频并
认养中意产品，参与活动的用户享有一系列认养特权（例如，署名、挂牌、邮寄认养荣誉证书、观看农牧产品的实时生长情况、价格折扣和优先发货），活动结束时再以按统一时间发货。认养活动结束后，商家（农场或合作伙伴、加盟商）进入备货期，通知用户准备发货。多出来的农牧产品可以通过正常方式下单购买。
在备货期且未发货前，参与认养活动的用户可以将部分或全部农牧产品（如果实、奶制品、肉制品等等）分享给好友（如好友未注册则需先完成注册），好友确认领取分享的产品后会给用户发送领取通知。
商家依据发货时间、用户地址、好友地址（如果有的话）、分享份数（如果有的话）发货。
用户确认收货后交易完成，商家与平台进行结算。
利益干系人
自营商户（农场）：扩大销售额，创造新品牌。加盟商：背靠一手货源，没有中间商，多赚钱。团购团长（分销商）：利润丰厚，分销创业。消费者：购买健康、新鲜、且可视化成长的直供农牧产品。平台：用互联网思维和技术改造供给侧，为市场提供鲜、快、好、省的农牧产品，合理赚取佣金。政府监管部门：维系食品安全，确保平台、商家和消费者的各项行为合法合规，并保护各方的利益。
商业模式画布
通过对利益干系人的目标描述，可以得到如下的商业模式画布。
业务目标
农场扩大销售额，提升销售面和知名度，同时和潜在合作伙伴一起营造良好营商生态。
激励用户参与活动，踊跃分享。
鼓励用户通过小程序分享活动、商品，成为分销推手，赚取佣金。
吸引社区团购团长在平台上选品、销售、运营。
吸引加盟商入驻平台。
低保真原型
主要作用就是将业务语言、业务流程、业务蓝图和业务用例等内容转换成直观的可操作的界面，捋清业务内涵和业务之间的关系，消除歧义。
这种工作既可以在业务分析进行，也可以在战略设计阶段进行。当然，还可以在这两个阶段都实施。
下面是商家在管理后台发布认养活动的部分原型。
下面是用户在小程序上参与认养活动的部分界面。
业务蓝图
基于业务描述、利益干系人、商业模式画布和业务目标，就可以形成最初的业务蓝图（或者称为核心业务）了。
所谓业务蓝图，就是一家企业能够显著区别于其他企业的业务特色、盈利模式和经营理念。
业务蓝图将成为业务的纲领性文件，后续的业务拓展和业务增值，也都是基于核心业务来完成的，它也用于从战略层面指导信息系统的开发工作。
在不断深入了解、分析、熟悉、验证业务的过程中，业务蓝图还可以依据实际情况不断调整，最终目标是优化流程、提升体验、减少交易环节和降低交易成本。
认养的粗略业务蓝图是这样的。
业务流程
蓝图可以提供业务的全貌，给具体的流程提供指导，但蓝图还是不能代替真正的流程，需要将蓝图细化为更具体的流程、分支及条件。
所以接下来，将以认养为例细化具体的业务流程。
具体的认养业务流程（部分）说明如下。
商家在发布活动前需要先上架相应商品（如之前已上架过则无需再次上架），审核通过后才能再活动中选择该商品。
商家发布认养活动，并同时上传认养的农牧产品的照片或视频、管理生长日志（不定期发布）、上传铭牌和证书模板。如果平台审核通过则活动可以按时启动。如果平台审核通过时间是在活动开始时间之后，那么同样视为审核失败。
商家发布了认养活动之后，在活动结束前，用户都可以参与认养。在小程序中浏览商家上传的图片、视频和生长日志，然后下单认养，也可以不参与认养商品而以普通方式购买。
参与认养的用户即可获得包邮的
认养荣誉证书，如认养活动结束后申请需要另付邮费。认养用户可以将自己得到的农牧产品分享给微信好友。认养活动结束后不能再参与认养，活动结束后与发货前属于备货阶段。在正式发货前，认养用户仍可以给微信好友分享认养的农牧产品，一旦开始发货则不能再分享。
业务用例
在完成了业务蓝图和基本的业务流程分析之后，就可以开始识别系统的业务用例了。
业务蓝图和业务流程从战略层面框定了整个系统的边界和业务流转逻辑，而业务用例将则是对其进行细化和解读。
在识别用例的过程中，也可以反向补齐业务蓝图或业务流程中可能搞错或遗漏的部分。
因为这里只关心用户和平台之间的认养业务关系，所以其他涉及到的角色的用例尽量简略。
如下是对认养业务用例（部分）的说明。
用例中的
平台是两种角色的混合：人工与系统。人工的作用在于：审核认养活动，并依据法律法规和平台政策，删除非法的活动图片或视频，以及一些非法或恶意的评论。系统的作用在于：当商家上传签名模板，并由客户签名后，会通过系统自动实现模板 + 签名的合成，然后供用户下载、分享，所以这里的用例将合成署名和通知用户查看铭牌做了特殊标记，代表是由系统自动实现，无需人工干预。用户的角色包含三类：
用户、用户的好友，以及通过发送链接成为分销推手的用户。认养活动一旦开始时且有用户参与后，商家和平台都无法单方面修改认养活动中的时间段相关信息，例如
活动开始-活动结束时间段、活动结束-备货时间段、备货时间-发货时间段等。但如果没有用户参与，则可修改各时间段信息，只要逻辑上不出错、时间段不重叠即可。不管活动是否已经开始，始终可以修改活动介绍、产品库存、活动图片等非关键业务信息。而产品库存一旦为
0，认养活动不管是否已到结束时间，都会在第一时间自动结束且进入备货阶段。所以商家需要设置好库存预警信息，避免活动意外地提前结束。当有用户参与认养时，如果有用户投诉认养活动涉嫌违法（不管是违反国家法律法规还是平台政策法规），且经过平台确认属实后，不管是否已有用户参与，平台将第一时间终止其认养活动、下架认养商品、封禁店铺并冻结商家对应的账户。
商家将用户署名的专属铭牌挂载到农牧产品身上后，需要再给用户推送消息告知，用户即可在专门页面中查看，也可以下载或分享，因此这里的
通知用户查看铭牌做了特殊标记。由于业务以电商交易作为承载平台，因此弱化了
社交功能方面的属性，例如，对生长日志的评论功能未做过多考虑。
补充说一点，有些公司或者研发团队倾向于在有了明确的用例文档之后才开工。
而我个人认为有产品原型 + 业务流程图 + 部分接口文档就已经可以开始动手写代码了，原因如下。
一是市场变化太快，对于很多中小企业、技术团队来说，验证模式远比完善文档更重要，而且很多需求本身就是不断变动的，更何况还不知道是不是伪需求，在开发初期就大费周章去完善文档，不值得。
二是因为不管是瀑布模型还是敏捷模型，其中必不可少的一个环节就是评审（原型 + 技术），完全可以将会议纪要、讨论内容作为非正式的用例文档，这样可以一举两得，既节约了研发的时间，又避免了原型或需求的歧义。
三是有些开发工作对于技术团队来说可能是第一次做。例如，有些开发工程师可能完全没有使用过某些平台的物流助手来生成发货电子面单，那么这部分流程就可能会和设计时的想法完全不一样，导致文档和实现脱节，进而给后续开发工作造成麻烦。
四是大部分的用例文档，其实在初次写好之后就极少有人再去更新了，所以与其寻求心里安慰，还不如多花时间更好地提升用户体验。
当系统或平台稳定运行一段时间后，可以在总结、复盘或者重构期间，再回过头来补齐用例文档，只有在这种时候，写出来的文档才能真正反应系统的设计思路和实现过程。
子域划分
有了以上的诸多业务信息，就可以尝试着划分DDD最粗略的业务子域了。
这里所说的子域划分是将完整的业务拆分为小块的业务模块或微服务，方便后续做战略设计时对各个业务模块再进行限界上下文识别。
如果以认养服务为核心，那么从整个平台较为完备的业务形态上来说，它可以被划分为如下子域。
这种划分出来的子域模型，我称之为足球模型。
对平台来说，最关心的就是加盟、商家（供给）和用户（流量）。
对商户来说，最关心的就是活动、商品和交易（包括订单、快照、退换货等）。
对推手来说，最关心的就是分销佣金。
上面这些就是整个平台的核心子域。除此之外，还有另外两种子域需要明确。
商家和团长都比较关心自身销售情况、可用的营销工具、货物的储存和运输等，所以就要开发这些与业务关联性比较强的工具。而对于平台来说，还需要做到最低限度的对黑灰产的抵御，以及完成对各种业务/系统消息的收发。以上这些相对于平台的核心业务来说就是
支撑子域。客服工单、财务管理（对账、结算、盘存等）、日志采集、认证授权、支付等业务模块在每个电商平台中都会有，而且业务属性相对较弱，功能也都大同小异，通常是不用公司自己开发的，基本是外购或集成的第三方软件（例如，用友/金蝶、ELK、OAuth 2.0等），所以它们都属于通用子域。
真实的电商平台子域远比这要多，但对于了解DDD来说是没有必要的。而且很多原来属于支撑子域的业务模块，现在其实也可以改为通用子域了，例如，仓储管理和统计分析。
至于每个子域各自的子域业务蓝图、子域业务流程和子域业务用例就不再展开细讲了。
总结
回顾整个历程，可以清晰地看到：从业务描述开始，到业务目标，到形成业务蓝图，再到业务流程和业务用例，以及最终的子域划分，每一个阶段的输出都是下一个阶段的输入，环环相扣，哪一环做得不好或者掉链子，都将会对整个系统产生很大的影响。
如果说对子域的划分是依靠经验和基本的业务模块属性来完成的话，那么战略设计和战术设计更多的则是需要细致且专业的分析了。
接下来，就可以从DDD的业务分析阶段进入到的战略分析环节了。
额外说明
不难看出，只要是涉及到订单这一块，绝大多数电商平台的总体流程几乎都是相同的。
绝大多数电商平台中订单的运行流程 这种围绕订单而构建的
电商交易模型，在所有的电商平台中都处于核心位置，它才是DDD存在的意义，也是DDD可以充分发挥优势的地方。掌握DDD的最终目的不是为了记住一些名词术语，而是为了克服MVC 所固有的那些缺点。所以只要掌握了DDD的核心思想，至于怎么用它，采用什么形式，完全取决于个人的习惯和喜好。
例如，有些地方可能会把
统一语言称为通用语言，把限界上下文称为有界上下文，或者把客户-供应上下文（U-D）称为客户端-服务器上下文（C-S），又或者在遗留系统上直接开始做战略设计，甚至做更具体的战术改造。这些都不重要，仅仅形式不同而已，只要能真正抓住DDD的灵魂（我称之为 让业务语义指导编码实现），那么不管白猫黑猫，抓到老鼠就是好猫。
感谢支持
更多内容，请移步《超级个体》。