TypeScript中的实用领域驱动设计(DDD)：为什么重要？

请停止将Java的OOP方法强加给TypeScript。

第一个显而易见的问题

为什么我必须在 TypeScript 中使用域驱动设计？

好吧，你不是的，就这样，你不是必须在 TypeScript 中使用域驱动设计的。

认为软件开发只有一种正确的方法，而DDD就是这种方法，这是一种谬论。如果真是这样，每个人都会毫无疑问地使用它。

我们可以应用许多不同的架构方法。我们可以使用事务脚本、分层架构和DDD。我们可以混合它们，并使用许多其他的原则，如KISS和SOLID。

没有银弹。

第二个显而易见的问题
 

如果我不需要在 TypeScript 中使用域驱动设计，为什么那么多人在讨论这个？

嗯，因为当我们决定使用某种模式时，知道如何正确使用它是很重要的。

就像在软件开发中没有银弹一样，我们也没有可以一直避免的方法。一切都是可能使用的。两难境地在于它的意义有多大，更重要的是——我们是否以正确的方式使用它。

有时候我们会选择过去已经使用过的方法，这是我们舒适区的一部分。然而，有时候我们会接触未知的东西，在这种情况下，我们很可能会犯错。

如果我们第一次使用一些我们不了解的东西，没有遇到任何问题，那可能只是我们极其幸运，很可能下一次我们会因为不了解的东西而感到痛苦。

但是DDD是一个很受欢迎的话题，以至于很多人认为他们知道它是如何工作的，什么时候使用它，它的主要目的是什么，以及如何应用它的原理。

我从面试中得到的经验是，至少95%的应聘者说他们知道DDD，甚至经常使用DDD。事实上，只有不到10%的人能解释什么是价值对象。

第三个显而易见的问题
 

什么时候应该在 TypeScript 中使用域驱动设计？

嗯，这要看情况。标准可以灵活变动。

首先，我会考虑应用程序的大小。在大多数情况下，它提供了关于选择哪种方法的讨论的开始论据。

如果我们讨论一个简单的从一个源到另一个源的导入的 worker，那么 DDD 就没有意义了。

如果我们谈论一个简单的 web 应用程序，它为一对实体提供 CRUD 操作，那么 DDD 就没有意义。

如果我们谈论一个没有复杂业务逻辑的领域，DDD 很可能是一种开销。

如果我们讨论一些基础架构代码、技术问题的解决方案，并且根本没有业务逻辑，那么我们可能不需要DDD。

如果我们谈论一个快速的演示，MVP，那应该为我们的项目带来一些观众和潜在的投资，但我们希望在重写之后，在这里，DDD可能是开销。

但是，如果我们谈论一个处理多个实体和围绕它们的复杂业务不变量的应用程序，我不能说我找到了比DDD更好的候选者。(但是，再次强调，这是我的意见。)

其次，我会考虑软件开发人员的个人经验和偏好。

如果我们谈论的是那些对替代方法感到满意并证明使用它们是有效的群体，那么DDD就没有意义。

如果我们谈论的是软件开发经验较少的群体，他们将需要一些时间来充分理解DDD是如何工作的。

如果我们谈论的是拥有足够的不同OOP范例经验的团队，并且有动力提供完全反映业务的代码，那么DDD就是要走的路。

如果具体到我来说，我每天都使用DDD。

第四个显而易见的问题
 

在 TypeScript 中使用领域驱动设计有什么好处？

嗯，有很多。我会给出一些：

1. TypeScript 完全兼容 DDD。TypeScript(或 JavaScript)是一种面向对象的编程语言，它完全支持所有必要的代码结构来描述 DDD 模式。

2. 使用DDD，代码可以更好地反映业务术语。当我们按照业务的精神命名类和方法时，我们可能会注意到我们与业务所有者的对话开始变得更加流畅。

3. 使用DDD，我们在代码中拥有更稳定的复杂业务不变量。我们的代码将业务不变量的逻辑放在正确的位置，并保护我们的数据免受错误操作。

4. 使用DDD，领域边界是清晰的。代码中的边界反映了现实生活中的边界，比如我们希望用应用程序呈现的公司不同部门之间的边界。

5. 使用DDD，测试用例反映了业务场景。当我们为代码定义测试用例时，我们的场景描述了来自业务的实际用例，而不仅仅是冷冰冰的数学计算。

6. 使用DDD，业务逻辑被放置在单一且正确的位置。完整的业务逻辑总是在一个位置，与周围系统的技术细节解耦。

7. 使用DDD，使用微服务是一条逻辑路径。值得注意的是，DDD是定义微服务边界的完美工具，单个微服务是保持足够复杂的业务逻辑的最佳场所。

8. 使用DDD，每个软件开发人员都成为业务分析师。拥有全职的团队成员来解决业务问题并拥有技术技能，此外，为我们提供了一个积极结果的最佳机会。

9. 等等...... 我可以添加更多的原因，但它们都将导致同样的结论 — 在我(谦虚的)看来，没有任何方法比DDD更好地利用技术解决业务问题。

最后一个显而易见的问题
 

我应该如何在 TypeScript 中使用域驱动设计？

嗯，这就是我开始写本系列的重点。

DDD中的许多模式都应该被解释清楚，即使是那些看起来很明显、每个人都知道的模式，比如实体。

根据我的经验，这种模式是最危险的，因为它们与来自不同架构方法的其他模式共享相同的名称，然而，它们不能解决相同的问题。

因此，在接下来的一段时间里，我将尽我所能提供一系列的文章，完成我在过去十年里学习和实践DDD时所能找到的所有指导方针和最佳实践。

所以，敬请期待。

 欢迎关注公众号：文本魔术，了解更多