DDD领域驱动设计

本体是针对“特定兴趣领域”的正式定义的词汇表（术语）。因为它是形式化定义的，它可以减少人类话语中混淆的机会，事实上，一些本体就是为此目的而创建的，也有为使得计算机程序能够推断关于领域的逻辑结果而创建的本体。 因此，开发本体可能是创建数据库、 专家系统或知识库的前奏。 对“特定兴趣领域”的限制可能看起

在本文中，将深入研究领域驱动设计(DDD) 以及许多困惑和讨论的主题：聚合设计。 首先简要概述什么是聚合，然后继续揭开业务不变量的神秘面纱，并在您必须打破聚合时提供实际考虑因素。 [b]什么是聚合？[/b

宜家撰写了关于其知识图谱系统和知识图谱层(KG)的文章。三层方法侧重于 概念：代表公司所做的业务概念。 类别：表示业务中使用的受控词汇或术语。 数据：代表企业的产品或独特的销售单位。 例如，在宜家，概念是产品，类别是书柜，一个数据点是BILLY 白色 80x28x202 厘米书柜。

EventStorming是一个系列的研讨会，基于在一个大的模型表面（通常是一个纸卷）上用便条实现集体讲故事。 Big Picture大图 是最大的规模的味道：它可以涉及相当多的人（25-30是典型的数字），并引导你探索整个业务线和结束。迭代法让参与者通过 "事件 "可视化其组织内的故事情节，增加

机器学习正在席卷全球，许多使用规则引擎做出业务决策的公司开始利用它。然而，这两种技术针对不同的问题。规则引擎用于执行需要 100% 精度的离散逻辑。另一方面，机器学习专注于获取大量输入并尝试预测结果。了解这两种技术的优势非常重要，这样您才能确定问题的正确解决方案。在某些情况下，不是其中之一，而是如何

领域驱动设计在康威定律中发挥作用，帮助定义组织结构： 因为 DDD 的一个关键部分是识别BC：BoundedContexts。 BC一个关键特征是它有自己的UL：UbiquitousLanguage，由在该上下文中工作的人定义和理解。 这样就可以围绕一个主题对人员进行分组的方式，与价值流

最昂贵的错误是：[b]业务逻辑通常保存在服务层中[/b]。 几乎每个人对服务层的定义都略有不同。阅读这篇文章的每个人可能也会对它的定义有所不同。但是，我注意到人们对服务层的定义之间的

如何绘制沃德利地图（Wardley Map） 的实践是困难的。我们将分解一些开始使用 Wardley Maps 所需了解的知识。但请记住，地图或映射，就像任何技能一样，需要练习；而且你练习得越多，你就会越好。 地图剖析

本文针对的是对DDD和聚合体有一定工作经验的人，这些例子使用了C#。然而，如果你熟悉任何OO语言，那么你也能跟上。 可以在此处查看 GitHub 问题域

在这篇博客中，我们将使用命令和查询责任分离（CQRS） +存储库模式建立领域驱动设计（DDD）架构，在docker的帮助下，我们使这个应用程序

虽然微服务一直被认为是领域驱动设计范式的实现，并以正在开发的单个服务的有界上下文为中心，但事实与现实相去甚远。虽然 DDD 方法在微服务世界中无处不在，因为它在域和子域中具有独立/隔离的问题区域，但如果仍然遵循传统的代码结构化方式，我们就会错过这个神奇世界的真正本质。 这篇文章将重点介绍我们今天遵循

如果参加DDD领域发现研讨会，发现洞察力的最有效和最简单的方法之一就是明确某事物的规模或大小。事物的规模会影响其重要性以及我们如何对待它。 将规模明确化可以带来各种见解，

在您当前的应用程序中，您的业务逻辑有多复杂？它的范围可能从微不足道到极其复杂。人们不应该为一个微不足道的问题使用复杂的工具。 我们大多数人，包括我自己，都习惯于编写所谓的事务脚本。我们编写一个

领域驱动设计 (DDD) 是一种构建软件的方法，它试图通过关注核心领域、构建领域的可进化模型以及让领域专家参与模型的进化来开发和确保解决业务的复杂性一致的理解和语言。您可以将域视为问题空间。例如，允许人们从当地的外卖店在线订购食物，并为餐馆提供在线服务和处理订单的能力，而无需对基础设施进行前期投资，

[b]1、有效的软件是与业务挑战相一致的软件[/b] 我们所说的一致，是指软件从领域中借用正确的术语，正确阐述业务的关键概念，并尽可能少地避免技术问题带来的意外的复杂性。 [b]2、康威定律不是一个可以选择不接受的选项。[/b] 它的作用有点像某些物理定律，如重力的

PayPal 撰写了关于采用数据网格原则的策略。该博客承认尚无标准实施，但建立了一个商业案例，说明 PayPal 在其数据策略中需要 DataMesh 原则。这是一个令人兴奋的从 PayPal 观察的空间。 随着企业变得更加敏捷，集中化越来越成为过去的世界，数据平台似乎也是如此。因此，我们正在构建一