通过营销活动实现客户/用户拉新、留存和促活是业界普遍采用的方法。为实现商户增长和留存，美团核心本地商业/商业增值技术部也构建了相应的营销系统来支撑商户的线上营销运营。在系统建设过程中，面临着业务体量大、行业跨度大、场景多样、客户结构复杂，需求多变等挑战。本文试图还原从0到1构建面向商户的营销系统过程中，并通过DDD（领域驱动设计）来应对系统设计和建设中遇到的业务复杂度高、需求多变、维护成本大等问题。
软件系统的复杂性主要体现在三个方面。
DDD（Domain-DrivenDesign，领域驱动设计）是应对软件设计复杂性的方法之一，它能很好的解决上述三个问题，但其概念体系复杂（如下图所示），学习曲线陡峭，即便深入研读DDD的两本经典著作，项目落地时依然有点“捉襟见肘”。
在展开介绍DDD之前，这里先回顾一下历史：
什么是领域？领域由三部分组成：领域里有用户，即涉众域；用户要实现某种业务价值，解决某些痛点或实现某种诉求，即问题域；面对业务价值，痛点和诉求，有对应的解决方案，这是解决方案域。什么是领域驱动设计？通俗地讲，针对特定业务，用户在面对业务问题时有对应的解决方案，这些问题与方案构成了领域知识，它包含流程、规则以及处理问题的方法，领域驱动设计就是围绕这些知识来设计系统。
以营销为例，营销系统所服务的用户有4类：运营、销售、电销人员和商户。解决3个核心问题：如何发券、发给谁、发什么（红包还是折扣券）。解决方案：通过营销活动来承载发券，不同的活动类型对应不同的玩法（如买赠、折扣、充送等）；通过目标人群来确定发给谁；通过权益来定义发什么（如：红包、代金券、折扣券等）。
战略设计之前，先要确定用例，也就是业务是怎么玩的，有几种常见的方法：
下图是营销系统的用例图（起初并没有这么完整，这是多次迭代后的结果）：
确定业务玩法后，接下来是统一语言。从用例里抽取概念，并对概念进行甄别（去伪存真，抽象合并）找到真正描述业务的概念。比如，有多种方式来描述活动规则：充值送规则、返还规则和档位等，技术可能会泛泛地称其为规则，业务人员则用档位来描述（比如充值送活动，充1000送100红包，充2000送300红包，充3000送500红包，那1000、2000、3000就是业务所认为的档位）。抽取概念时，尽量采纳业务侧的叫法，这样统一语言比较容易推行。
接着是明确概念的含义，概念由术语、Term（术语的英文版）和含义三部分构成。含义明确的术语就是统一语言，这些术语将用在日常需求沟通、产品文档，技术设计以及代码实现中。
明确概念后，接着理清概念之间的关系（1对1，多对1，多对多），确定概念所代表的的业务实体的核心属性和行为，从而得到概念模型。后续在业务需求讨论、产品和技术方案设计时，基于这个概念模型，使用统一语言进行描述，大家能很容易对齐；同时精心抽出的概念和建立的概念模型更接近业务本质，为后续的战术设计打下了基础。
基于统一语言和概念模型，业务-产品-技术三个角色比较容易就需求达成共识，保障沟通的一致性。
概念模型是一张大网，描述了概念间的关系以及关键属性，但还不能直接映射为代码模型，要映射为代码模型，还需拆解，化繁为简。
本源论认为世界的本质是简单的，复杂问题由多个简单问题构成；康威原理认为系统架构受制于组织沟通架构，系统落地时，首先要确定系统边界，再依据系统边界组织分工。这两个原理表明：我们可以将复杂问题拆解为多个简单问题，并针对团队资源组织分工协作。
这里提供一种拆解方法（来自美团内部）给出了一种拆解方法：按纵和横两个维度来拆，纵是从业务价值和目标维度划分，横是从功能的通用性维度划分。这里尝试从业务角度来拆，没有系统支持时，业务要在线下运转，通常根据要达成的业务目标，将业务流程或业务组分拆解为多个节点，并定义每个节点的职责以及对应的规范和标准，安排对应的组织或人员执行。简单地说，就是从业务问题和解决方案出发，拆解到对应的人。因此基于业务的拆分通常能实现系统用户、业务问题和解决方案之间的一致性。业务系统是把业务的玩法从线下搬到线上，在进行系统拆分时，也可以使用这个思路。从三个层面来进行：
营销系统基于问题域拆解为五个子域（活动域，权益域，人群域，推送域，数据域），每个子域解决特定的问题，各子领域相对内聚和简单：
下图是营销系统的整体上下文关系：
有了战略设计，构建了统一语言和概念模型后，如何验证概念模型呢？通常用两个方法：
战略设计得到了概念模型，战术设计则是将概念模型映射为代码模型，有很多编程范式，比如事务脚本、表模式、面向对象，函数式等，最好的方式是面向对象的实现。
从概念模型到对象模型：
两类对象：实体和值对象，这两者的区别是是否有统一标识和自己的状态。
有了对象模型，还需通过聚合根完成封装，如何确定聚合根的粒度？营销活动包含活动、库存、档位、档位项、目标人群五个对象，如果采用小聚合根模式，一个对象对应一个聚合根，这样每个聚合根都很简单。但从业务角度看，库存或档位会影响活动的状态，如：修改了库存或档位，活动需要重新审批和上下线，这种业务上的耦合需要在技术上进行处理。此时，就得在小聚合根上构建领域服务来封装这些逻辑。
聚合根的设计要遵循一定的原则：
如下图是营销系统的聚合根：
聚合根已经非常接近代码实现，落地代码时，大家还会纠结用贫血模型还是充血模型。SpringMVC通常运行在单例模式下，引入充血模型会增加理解成本和技术复杂度。另外，不适合放在聚合根里的领域逻辑，可以放在领域服务里，如：同时存在多个充值送活动时，用户只能参加优先级最高的一个，在充值送活动聚合根里会标识活动的优先级，但挑选优先级最高的活动并非聚合根的职责，但确实是领域逻辑的一部分，此时可通过领域服务实现。
从概念模型，类模型到代码实现，整个过程都要使用统一语言。在落地代码时，代码要体现出业务含义，比如下图的例子，要避免左边updateStatus()这样的方法，它没有体现业务含义（必须阅读代码实现，才知道这个方法做了什么）；图中右边的submitCampaign()，approveCampaign()，cancelCampaign()则有明确的业务含义。
完成战术设计后，如何组织代码架构？无论是六边形架构，整洁架构还是洋葱架构本质上都是围绕着领域模型展开，应用层、基础设施层和外部接口都依赖领域模型：
下图是我们团队的工程实践，与前面三个图本质上是一样的。领域层和应用层次放在中间（两者都属于领域逻辑），基础设施和用户接口依赖中间层：
在聊需求的那一刻，设计就开始了，统一语言就是设计的一部分。
解决方案域在模型维度分为四层：
这里有两个陷阱：
另外，领域至少可以分为两大类：一是学科型，比如财务、会计、图形学、动力学，这类系统的设计须先深入理解学科知识；二是实践型，如CRM、订单交易等，是业务经验的总结，这类系统的设计不妨参考前人的实践。当然，如果自己的业务具有独特性，那就只能靠自己摸索了。