• DDD领域驱动设计与OO面向对象之间是有区别的，面向对象更注重抽象，从差异中寻找共同点，然后将其抽象出来；而DDD更注重上下文边界，这种边界代表区分差异。其实这是两种不同的思维方式。 在[url=
  • 作为软件工程师和架构师，我们经常面临为遗留系统创建目标微服务架构的挑战。这些系统通常是已经存在多年的大型单体应用程序，通常具有很多依赖性，并且通常在您的公司中没有一个人了解这一切。在这些情况下，一群领域专家是理解围绕业务上下文和所需功能的“原因”的关键，上下文对于创建成功的架构至关重要。 通常，您首
  • 诸如Scrum等管理风格是以较短的开发周期为中心，也就是冲刺，许多组织误解了这一点，并采取“无前期设计”和“从第一天开始编码”的方法。 对他们来说，理论上我们不需要设计软件解决方案。我们开始编码，但增量很小。在每个冲刺结束时，向产品所有者和利益相关者展示工作软件的演示。利益相关者提供反馈，然后我们修 icon
  • 在商业、技术和一般领域，“领域”一词经常出现，并在各种上下文中具有许多不同的含义。当与使用不同定义的不同公司或社区合作时，这有时会变得棘手。 一般的问题是，当我们使用像领域这样的通用和模糊词时，我们会做出假设，将重点放在听者身上，以正确确定上下文并选择正确的含义。 由于领域在我们的世界中是如此常见， icon
  • 假设有一个农业机械零件的批发商。他们建立了一个 B2B 网上商店，供经销商和机器维修公司订购。在他们无处不在的统一语言与术语中，订单代表了这个自动化流程：它使客户能够挑选产品，应用正确的折扣，并将其推送到 送货。 icon
  • 端口和适配器是一种架构模式，旨在将您的应用程序与细节解耦。 我的经验证实了这一说法。在最近的一个项目中，我们的团队决定从端口和适配器架构开始，随着我们团队的成长，它得到了回报。我们的团队正在构建一些需要集成的服务。端口和适配器让我们可以进行一些集成，并将我们的域模型与我们的数据库模式分离，这为我们的 icon
  • 领域驱动设计的主流思想是关于实体、值对象、聚合、存储库、服务、工厂……各种技术模式。因此，大多数人认为他们不需要领域驱动设计，因为这对他们的领域来说很复杂。 为什么你需要所有这些“东西”？好吧，也许你不需要！ 在一个大型系统中，如果您正确使用存储库模式，建模您的 icon
  • 这是Oliver Human & Paul合著的[url= - Cilliers[/url]的第 17 章——走向复杂的经济： 定义复杂性的不是相互作用的部件数量，而是它们相互作用的性质：这些相互作用 icon
  • 在构建业务关键型软件时，像领域驱动设计这样的实践是把一个重要的焦点放在IT和领域专家协作上。此外许多公司还看到了与客户更亲密的关系，更好地了解他们的愿望和需求，从而建立更忠诚的客户群的必要性。这就是服务设计、用户体验研究和敏捷概念（如用户故事）的亮点所在。用户故事图能帮助我们设计出既可行又有价值，而 icon
  • 将大型复杂系统模块化为更小、更易于管理的部分是很好的最佳实践，不仅可以降低每个部分的认知负担，还可以实现团队独立性和操作弹性。 棘手的一点是如何划定边界？为整个系统建立一个稳定和可持续的结构。基于有界上下文的领域驱动设计是一种方法，其中是使用领域语言作为指导，另一种方法是从业务模型定义的能力中汲取灵 icon
  • NorthOne是为小型企业提供银行服务的公司，他们是如何结合serverless和领域驱动设计以及EDA实现银行工作流程的？ NorthOne为小型企业提供银行服务。实际上，NorthOne是一个存款账户，具有许多集成功能，几乎就像是小型企业的操作系统。基本上，NorthOne会选择最好的合作伙伴 icon
  • Spotify 以开发一种吸引大量关注的工程文化而闻名：一切都围绕着创建“小队squads”；许多产品团队试图效仿它，但很少有人能成功。尽管 Spotify 不再使用产品小队，但该方法可以为其他敏捷产品团队带来好处。在本文结束时，您将对 Spotify Squad 框架有一个清晰的了解，以及哪些部分 icon
  • 这篇博文概述了盛宝银行（Saxo Bank）在数字化转型过程中如何通过DDD+数据网格架构实现：快速解决集成并将能数据快速交付给需要它的人。盛宝银行集团（SaxoGroup）成立于1992年，是一家欧洲全牌照 icon
  • “在某些实体中，整体（DDD聚合）的行为既不能从其单个元素得出，也不能从这些元素组合的方式得出；恰恰相反：任何部件的属性都由整体的内在结构规律决定。 ” -Max Wertheimer, 1924 马克斯·韦特海默（Max Wertheimer，1880年4月15日～1943年1 icon
  • 具有讽刺意味的是，强调无处不在的语言的 DDD 社区搞砸了这么多预先存在的DDD术语： DDD聚合Aggregate这个词语准确吗？ “聚合”完词语可能全过载。DDD社区意见领袖mathias将其视为“确定性单位”，它是某些数据和规则的一致性边界，在此边界内，您具有原子性、无并发性和无分布性。它不仅 icon
  • 从领域原语构建的正确领域模型会迫使我们开发人员做正确的事情。 让我们想出一个简单的 Java 方法签名示例： String foo(String str); 这段代码有什么作用？签名只告诉我们它是一个方法：它对输入字符串执行某些操作，或者它可能无法执行某些操作并返回null，或改变某些状态，或执行其 icon
  • 领域驱动设计是您应该了解的概念——无论您是开发人员还是领域专家。使用 DDD 处理复杂的软件项目。 领域驱动设计 (DDD) 的概念是由 Eric Evans 提出的。早在 2004 年，他就在他的著作领域驱动设计（又名“蓝皮书”）中写到了这一点。 DDD 上下文中的域是什么？ 一种知识、影响或活动 icon
  • 在 REST API 中使用布尔值坏处： 会阻碍API 可扩展性 会屏蔽和混淆域清晰度 会妨碍代码 可读性和可维护性 让我们深入研究这些领域并审核布尔值在 REST API 中的常用方式。 API 可扩展性 一个可扩展的 API应该让未来的变化显而易见并且易于实施。它不应引入复杂性或不必要的重 icon