领域驱动设计批评与实践

1. DDD领域驱动设计批评文集领域驱动设计（DDD）是一种软件设计方法，它强调以业务领域为中心进行软件开发。然而，任何设计方法都有其局限性。以下是对DDD批评的文集，探讨了DDD在实际应用中可能遇到的问题和挑战。

2. 做强化自测题获得“软件方法建模师”称号成为一名软件方法建模师不仅需要理论知识，更需要实践能力的证明。通过以下链接参与强化自测题，检验你的建模能力，争取获得这一荣誉称号。

3. 《软件方法》各章合集《软件方法》一书深入探讨了软件开发的各个方面。以下是该书各章节的合集，为读者提供了一个全面的学习资源。

4. 京东云开发者DDD妙文欣赏《京东云开发者DDD妙文欣赏》是一系列文章的集合，它们以DDD为主题，从不同角度分析和讨论了DDD的理论与实践。这些文章现被合并成一篇，方便读者阅读和参考。

京东云开发者原文链接DDD落地实践-架构师眼中的餐厅

内容赏析我们将逐个截图来赏析《餐厅》这篇文章，探讨DDD在实际业务场景中的应用和效果。

以上是对所提供链接内容的重新编写和结构化整理，旨在为读者提供一个清晰、有条理的阅读指南。

领域驱动设计分析与实践

领域驱动设计概述领域驱动设计（DDD）是一种软件开发方法论，它强调以业务领域为中心进行软件开发。本文将探讨DDD在实际项目中的应用，以及如何将DDD的核心思想与架构和功能设计方法论相结合。

核心思想与方法论结合在软件开发中，领域驱动设计作为核心思想，需要与架构设计和功能设计方法论相结合。这种结合不是简单的叠加，而是相互渗透和补充，以达到更全面的系统设计。

餐厅设计案例本文以设计一个餐厅为例，展示如何将DDD应用于实际项目。我们关注的是设计的整体框架，而非具体的实现细节。

领域分析与设计- 领域分析：从纯业务视角出发，分析业务需求和问题。- 领域设计：基于分析结果，进行业务领域的划分和设计。

行为区域划分通过对餐厅业务流程的宏观分析，我们可以迅速识别出关键的行为区域，例如菜品、订单、厨房和用餐等。这些区域将成为后续详细分析和设计的基础。

领域划分的深入每个行为区域都对应一个业务级别的领域，如菜品域、订单域、厨房域和用餐域。这些领域需要单独进行深入分析，以确保设计能够满足业务需求。

UML图的运用文章中穿插了UML图的使用，旨在展示如何通过图形化的方式体现领域驱动设计的核心思想。UML图的使用应有助于更好地理解和沟通设计思路。

结论通过本文的分析和实践，我们可以看到领域驱动设计在实际项目中的应用是多维度和灵活的。它不仅仅是一种设计方法，更是一种思考问题和解决问题的视角。

期待与展望希望读者能够耐心阅读本文，从中获得有价值的见解和启发，以促进自身在领域驱动设计领域的深入理解和实践。

图2 映射关系

先不说按照流程顺序来划分领域是否合适，就算一定要这样划分，是不是应该把流程画得细一点？从这么四步，还真看不出怎么就刚好推导得到这四个领域？

哎，往下翻，还真有一张：

图3 原文的“用例流程图”

为了不打乱逐个截图赏析的顺序，我们等到出现图3的地方再正式赏析这张“用例流程图”。

**********

领域驱动设计中的统一语言分析

1. 统一语言的定义与误解在领域驱动设计（DDD）中，统一语言是一个关键概念，它指的是在软件开发过程中，领域专家和开发人员之间共享的一套术语和概念。然而，有些人可能会将这简单理解为词汇的罗列，这是一种误解。

2. 统一语言的实践与误区- 视频与文章资源： - DDD领域驱动设计伪创新之通用语言 01 - DDD领域驱动设计伪创新之通用语言 02- 书籍参考： - 《软件方法》第8章，详细讨论了DDD中的统一语言问题。

3. 概念定义与分类- 泛化关系：例如，厨具包含铲子、锅、菜刀等，这是一种集合的包含关系。- 关联关系：如一次做饭可能包括买菜、洗菜、切菜、烹等步骤，是个体的组装。

4. 概念与实例的区分- 概念定义：通常指的是一个类别或类别的属性。- 实例：如京酱肉丝、烤鸭，它们是菜品的具体实例，而非领域概念。

5. 领域概念的提炼- 领域概念的提炼不应仅限于菜品的名称，而应深入到菜品与食材之间的关系，例如京酱肉丝的制作需要哪些材料及具体用量。

6. DDD的实践建议- DDD的实践不应仅仅停留在概念的罗列，而应深入分析和理解领域内的实体、关系及其相互作用。

7. 结论统一语言是DDD中促进沟通和理解的重要工具，正确理解和应用统一语言对于软件项目的成功至关重要。

图5 相声《报菜名》，马志明、黄族民

以前我画过的一张餐饮领域的类图，供参考：

餐饮领域类图解析

引言在本文中，我们将对图6的餐饮领域类图进行深入分析。首先，我们要认识到，尽管“简单罗列”这一表述在文中多次出现，但其背后的意义远比字面所表达的要复杂。

流程图的历史与发展流程图作为一种图形化表示方法，其起源可以追溯到1921年，由Gilbreth等人在机械工程领域首次使用。随后，Goldstine和von Neumann将这一概念引入计算机科学，用于描述程序的逻辑流程。在统一建模语言（UML）中，流程图被称为“活动图”。

流程图的价值尽管流程图的名字暗示了它主要关注流程的流转，但其真正的价值在于展现程序或业务流程中的分支和循环等控制逻辑。如果流程图仅仅用于展示流程的线性流转，那么当初von Neumann等人完全可以继续使用文本描述。

个人经验分享在之前的工作中，我绘制了一张活动图（流程图），它不仅展示了基本流程，还详细描绘了其中的分支和循环逻辑。这张图可以作为参考，帮助我们更好地理解流程图的深层含义和应用价值。

结论通过对餐饮领域类图的分析，我们可以看到，无论是在机械工程还是计算机科学，流程图都是一种强有力的工具，用于清晰地表达和理解复杂的逻辑流程。

在软件设计领域，领域驱动设计（Domain-Driven Design, DDD）是一种非常受欢迎的方法论，它通过将复杂问题分解为更易于理解和处理的领域模型来简化开发过程。以下是对领域驱动设计及其在用例图绘制中的应用的详细阐述：

领域驱动设计概述领域驱动设计是一种软件设计方法，它强调以领域模型为中心进行软件开发。这种方法论通过识别业务领域中的实体、行为和关系，帮助开发者构建出更符合业务需求的软件系统。

用例图的绘制用例图是UML（统一建模语言）中的一种图表，用于描述系统的功能需求。在领域驱动设计中，用例图可以有效地展示系统的用例以及它们之间的关系。

用例流程图用例流程图进一步细化了用例图中的功能流程。它详细描述了每个用例的执行步骤，包括不同的分支和条件。

领域驱动设计的优势领域驱动设计之所以受到开发人员的青睐，是因为它降低了设计复杂系统的门槛。通过将复杂问题分解为简单的领域模型，开发人员可以更容易地理解和实现系统需求。

DDD架构师的角色在DDD实践中，DDD架构师扮演着至关重要的角色。他们不仅需要深入理解业务领域，还需要将这些知识转化为领域模型，指导开发团队进行软件开发。

结论通过领域驱动设计，开发人员可以更高效地处理复杂问题，构建出更符合业务需求的软件系统。用例图和用例流程图是实现这一目标的重要工具。

图8《餐厅》中的“用例图”分析

一、用例图的理解

在审视图8时，我们首先注意到标题“用例图”，并非其他类型的图。这提示我们，接下来的分析将基于用例图的相关知识。

二、用例图的构成要素

2.1 角色与动作的对应关系

厨师：负责做菜。这里与“统一语言”中的“做饭”有所差异，但实质上指的是同一行为。
其他动作包括买菜、洗菜等，与脑图中的描述保持一致。

2.2 用例的实质理解用例的核心在于“A使用X来完成B”，或“X向A提供了B的服务”。这里的关键在于X，即用例描述的是一个整体对外提供的价值。

三、图9的图形表达分析图9提供了两种不同的图形表达方式，但无论哪种方式，都需要明确研究对象X。没有明确的X，用例的讨论将失去意义。

四、用例图的深层含义用例图不仅仅是描述动作，它更深层次地反映了一个系统或服务如何满足用户的需求，以及这些需求是如何被实现的。

五、结论通过对图8和图9的分析，我们了解到用例图是一种强有力的工具，它帮助我们理解系统的功能和用户的需求。正确的理解和应用用例图，可以更好地进行系统设计和需求分析。

在讨论用例图时，我们需要明确研究对象X是什么。用例图是用来描述系统或组织提供的功能和与之交互的外部实体的。以下是对上文的重新编写和结构化：

系统用例图的基本概念- 系统X：可以是人、非人智能系统，或时间。系统X与外部系统A交互，其中A是系统执行者，B是系统X为A提供的用例。

组织用例图的基本概念- 组织X：可能是企业、政府机构、社会团体等正式或非正式组织。组织X与外部组织A交互，A是业务执行者，B是组织X为A提供的业务用例。

用例图的实例分析- 薛定谔的餐厅：一个概念性的讨论，用以说明用例图的不确定性和多义性。

如果“餐厅”指的是“餐饮企业”- 餐饮企业：作为一个组织，其存在的目的不是为员工提供就业，而是为顾客提供用餐服务。- 业务工人：如厨师、刀工、采购员，是餐饮企业内部的角色，但不是用例图的Actor。- 用例图示例：图10展示了餐饮企业的用例图，用“食客”代替了“顾客”，更准确地描述了企业与顾客的交互。

用例图的重要性- 用例图帮助我们理解系统或组织提供的价值和功能，以及与外部实体的交互方式。

用例图的绘制要点- 明确研究对象X，确保用例图具有实际意义。- 区分内部角色和外部Actor，正确表示系统或组织的用例。

结论用例图是需求分析和系统设计的重要工具，它要求我们清晰地定义研究对象和外部实体，以确保设计的有效性和实用性。

图10 “餐饮企业”的用例图

图10代表了“餐饮企业”的价值，非常稳定。时光倒流三百年，图10也是成立的，往后一百年，也应该是成立的……吧？

容易变的是用例的实现，即“餐饮企业”的业务流程。图11是某餐饮企业“***餐厅”于2018年的业务流程片段。可以看到，“食客扫码点餐”等场景尚未出现在当时的业务流程中。

在分析2018年某餐饮企业的业务流程时，我们可以将注意力集中在图11所展示的序列图上。该图详细描述了餐厅内部的业务流程片段。首先，我们注意到’厨师’这一角色在业务流程中扮演着重要角色，但与’取号系统’和’餐馆管理信息系统’等其他系统并没有直接的交互。尽管存在一条虚线指向’厨师’，但这并不意味着’厨师’是这些系统的’Actor’。接下来，我们进一步分析’取号系统’和’餐馆管理信息系统’。这两个系统是餐厅业务流程中的关键组成部分，它们负责管理顾客的订单和提供必要的业务信息。然而，‘厨师’与这些系统之间缺乏直接的交互，这表明’厨师’在业务流程中的角色是执行而非管理。此外，‘厨师→做菜’这一动作虽然在餐厅的日常运营中至关重要，但它并不构成一个用例。用例通常指的是系统与用户之间的交互，而’厨师’在这一过程中更多地是执行者而非用户。总结来说，图11的序列图向我们展示了餐饮企业内部的业务流程，其中’厨师’虽然重要，但并不直接参与到’取号系统’和’餐馆管理信息系统’的管理活动中。‘厨师’的角色和职责清晰地界定了其在业务流程中的位置。

图12 厨师不是Actor

★什么情况下，厨师会是Actor？

一种情况是，研究对象是一个组织，厨师作为组织外的一个人群和该组织交互。

例如，以“餐饮协会技能评定中心”为研究对象，“厨师→考厨师证”就是用例。

图13 厨师作为执行者，例1

思考题：

多年前，电子支付还没有普及。有一家较大的餐饮企业，发薪水都是发现金。假设我们去观察，可能会看到一名厨师到财务部去领薪水。请问“厨师→领薪水”是“财务部”的用例吗？

另一种情况是，研究对象是一个系统，厨师作为系统外的一个系统和该系统交互。

例如，以封装了一些烹调智慧的“智能烹调机”为研究对象，“厨师→做菜”就是用例。

图14 厨师作为执行者，例2