区分问题和解决方案是领域驱动设计的秘诀
这听起来很平常吗？不是。问题解决短路是人们在压力下最常犯的错误（灯下黑），我们都处于压力之下
要探究原因，让我们依靠Vlad Khononov的学习领域驱动设计：调整软件架构和业务战略。
一切始于人
在 Khononov 的书的开头，有一个简短的提醒软件行业的人经常忘记的一个简单事实：
DDD 提醒我们，软件开发人员并不是唯一参与构建软件的人。
每个人都知道，在制作软件时，业务人员是相关的。在实践中不太确定的是，业务人员在软件构建的每个步骤中都至关重要，而不仅仅是在概述高级需求方面。
为什么？因为业务人员是问题的代表，也是解决问题的价值的代表。他们进入问题空间。
软件开发人员进入解决方案空间，这是解决问题的成本。
人很重要。
那么心态很重要
软件开发是一个垂直的专业领域。它对构建软件至关重要：这是显而易见的。然而，还需要更多，因为软件开发作为一门学科，专注于解决方案，但软件开发人员只有在明确定义解决方案的业务领域时才能控制解决方案。
什么是业务域？再次引用 Khononov：
业务领域定义了公司的主要活动领域。一般来说，它是公司为客户提供的服务。
和
为了实现其业务领域的目标和目标，公司必须在多个子领域中运营。子域是细粒度的业务活动区域。
听起来是不是很震撼？如果您是必须构建解决方案并且有严格的截止日期的软件开发团队成员，那么它确实如此。这就是为什么问题解决短路（灯下黑）是一个容易犯的错误的原因：仓促。
以及导致仓促控制人们的思想和行为的不适当的心态。
业务域及其子域设置了问题的上下文。当软件开发没有驯服该上下文并立即制定解决方案时，短路就会发生——由于缺乏策略，一个可能效率低下的解决方案。
战略
战略设计是 DDD 的第一阶段。这就是问题的焦点所在，请记住，这是一个为桌面带来价值的问题。
回到人身上，制定战略需要领域专家。将一些经验丰富的业务分析师甚至软件开发人员视为领域专家是一个容易犯的错误。相反，再次引用 Khononov：
领域专家既不是收集需求的分析师，也不是设计系统的工程师。领域专家代表业务。他们是首先发现业务问题的人，也是所有业务知识的来源。
领域专家提供业务语言。我将用整篇文章来介绍无处不在的语言；目前，最重要的是让业务语言成为设计战略的基础。
该策略旨在通过识别构成业务的不同子域的边界来管理决策。允许检测的是业务细分：
- 核心子域：这是投资的地方，因为它代表了解决业务问题的竞争优势。其业务逻辑复杂。
- 通用子域：这是购买或外包解决方案的地方，因为市场上的所有公司都这样做。
- 支持子域：这是支付维持核心子域的地方。它的业务逻辑很简单。
战术
战术设计是 DDD 的第二阶段。这是解决方案的重点所在，请记住，解决方案是解决问题的成本。
让我重复这个重要的事实：解决方案是有代价的。就解决的问题带来的价值而言，解决方案是值得付出的成本。
战术设计值得专门写一篇文章。现在，我只是将它与战略设计进行比较，以表明战术设计正在实现业务逻辑，因此是解决方案——一个独特的、独立的思维系统。
结论
区分问题和解决方案的 DDD 配方提供了最相关的成分：单词。在这种语言中，“战略”和“策略”具有深刻的含义，不再是无意义演示的流行语。
要点：问题带来了价值，而解决方案就是解决该问题的成本；这就是为什么让它们与众不同是至关重要的。