设计模式与领域驱动

「爱情、让人受尽委屈。」 2022-12-29 04:50 150阅读 0赞

想研究下设计模式，有机会读到了一篇美团开发者的一篇文章结合，从营销业务出发，介绍了领域模型到代码工程之间的转化，从DDD引出了设计模式，详细介绍了工厂方法模式、策略模式、责任链模式以及状态模式这四种模式在营销业务中的具体实现。对于营销业务来说，业务策略多变导致需求多变是我们面临的主要问题。如何应对复杂多变的需求，是我们提炼领域模型和实现代码模型时必须要考虑的内容。DDD以及设计模式提供了一套相对完整的方法论帮助我们完成了领域建模及工程实现。其实，设计模式就像一面镜子，将领域模型映射到代码模型中，切实地提高代码的复用性、可扩展性，也提高了系统的可维护性。

当然，设计模式只是软件开发领域内多年来的经验总结，任何一个或简单或复杂的设计模式都会遵循上述的七大设计原则，只要大家真正理解了七大设计原则，设计模式对我们来说应该就不再是一件难事。但是，使用设计模式也不是要求我们循规蹈矩，只要我们的代码模型设计遵循了上述的七大原则，我们会发现原来我们的设计中就已经使用了某种设计模式。  
原文[直连][Link 1]

> 业务策略多变导致需求多变，是业界很多技术团队面临的最具挑战的问题之一。那么如何设计一套易于扩展和维护的营销系统呢？今天的文章来自美团外卖营销技术团队，他们分享了从领域模型到代码工程之间的转化，从DDD引出了设计模式，并详细介绍了工厂方法模式、策略模式、责任链模式以及状态模式这四种模式在美团营销业务中的具体实现，将理论与实践进行了一次深度结合。

随着美团外卖业务的不断迭代与发展，外卖用户数量也在高速地增长。在这个过程中，外卖营销发挥了“中流砥柱”的作用，因为用户的快速增长离不开高效的营销策略。而由于市场环境和业务环境的多变，营销策略往往是复杂多变的，营销技术团队作为营销业务的支持部门，就需要快速高效地响应营销策略变更带来的需求变动。因此，设计并实现易于扩展和维护的营销系统，是美团外卖营销技术团队不懈追求的目标和必修的基本功。

本文通过自顶向下的方式，来介绍设计模式如何帮助我们构建一套易扩展、易维护的营销系统。本文会首先介绍设计模式与领域驱动设计（Domain-Driven Design，以下简称为DDD）之间的关系，然后再阐述外卖营销业务引入业务中用到的设计模式以及其具体实践案例。

设计模式与领域驱动设计

设计一个营销系统，我们通常的做法是采用自顶向下的方式来解构业务，为此我们引入了DDD。从战略层面上讲，DDD能够指导我们完成从问题空间到解决方案的剖析，将业务需求映射为领域上下文以及上下文间的映射关系。从战术层面上，DDD能够细化领域上下文，并形成有效的、细化的领域模型来指导工程实践。建立领域模型的一个关键意义在于，能够确保不断扩展和变化的需求在领域模型内不断地演进和发展，而不至于出现模型的腐化和领域逻辑的外溢。关于DDD的实践，大家可以参考此前美团技术团队推出的《领域驱动设计在互联网业务开发中的实践》一文。

同时，我们也需要在代码工程中贯彻和实现领域模型。因为代码工程是领域模型在工程实践中的直观体现，也是领域模型在技术层面的直接表述。而设计模式，可以说是连接领域模型与代码工程的一座桥梁，它能有效地解决从领域模型到代码工程的转化。

为什么说设计模式天然具备成为领域模型到代码工程之间桥梁的作用呢？其实，2003年出版的《领域驱动设计》一书的作者Eric Evans在这部开山之作中就已经给出了解释。他认为，立场不同会影响人们如何看待什么是“模式”。因此，无论是领域驱动模式还是设计模式，本质上都是“模式”，只是解决的问题不一样。站在业务建模的立场上，DDD的模式解决的是如何进行领域建模。而站在代码实践的立场上，设计模式主要关注于代码的设计与实现。既然本质都是模式，那么它们天然就具有一定的共通之处。

所谓“模式”，就是一套反复被人使用或验证过的方法论。从抽象或者更宏观的角度上看，只要符合使用场景并且能解决实际问题，模式应该既可以应用在DDD中，也可以应用在设计模式中。事实上，Evans也是这么做的。他在著作中阐述了Strategy和Composite这两个传统的GOF设计模式是如何来解决领域模型建设的。因此，当领域模型需要转化为代码工程时，同构的模式，天然能够将领域模型翻译成代码模型。

设计模式在外卖营销业务中的具体案例  
图片

为什么需要设计模式

营销业务的特点

如前文所述，营销业务与交易等其他模式相对稳定的业务的区别在于，营销需求会随着市场、用户、环境的不断变化而进行调整。也正是因此，外卖营销技术团队选择了DDD进行领域建模，并在适用的场景下，用设计模式在代码工程的层面上实践和反映了领域模型。以此来做到在支持业务变化的同时，让领域和代码模型健康演进，避免模型腐化。

理解设计模式

软件设计模式（Design pattern），又称设计模式，是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了可重用代码，让代码更容易被他人理解，保证代码可靠性，程序的重用性。可以理解为：“世上本来没有设计模式，用的人多了，便总结出了一套设计模式。”

设计模式原则

面向对象的设计模式有七大基本原则：

开闭原则（Open Closed Principle，OCP）

单一职责原则（Single Responsibility Principle, SRP）

里氏代换原则（Liskov Substitution Principle，LSP）

依赖倒转原则（Dependency Inversion Principle，DIP）

接口隔离原则（Interface Segregation Principle，ISP）

合成/聚合复用原则（Composite/Aggregate Reuse Principle，CARP）

最少知识原则（Least Knowledge Principle，LKP）或者迪米特法则（Law of Demeter，LOD）

简单理解就是：开闭原则是总纲，它指导我们要对扩展开放，对修改关闭；单一职责原则指导我们实现类要职责单一；里氏替换原则指导我们不要破坏继承体系；依赖倒置原则指导我们要面向接口编程；接口隔离原则指导我们在设计接口的时候要精简单一；迪米特法则指导我们要降低耦合。