限定上下文BC

为什么我们系统的模块耦合度如此之高？是因为他们缺乏凝聚力吗？（banq注：为什么人员在团队之间流动这么频繁？为什么团队之间开会如此频繁？是因为这些团队内部缺乏凝聚力吗？缺乏核心凝聚吗？） 案例：有人说：我们的系统是自 COBOL 和 FORTRAN 时

企业家不能非理性地执着于创新，当然在某些情况下是绝对需要新鲜的想法，但如果对原创性产生依恋，或厌恶拷贝他人开创性想法，也会导致成功的重大延迟（甚至失败）。此外，一次性做好几件事总是比做好一件事困难得多。因此，企业家应该努力弄清楚交付给客户的整体解决方案的哪些方面需要独创性，而其他一切

在Airwallex，领域驱动设计（DDD）方法被用来指导如何对复杂的业务问题和系统设计进行建模。在这篇博客中，我们试图全面介绍用DDD模式对支付系统进行建模的做法。 简介支付系统是一个相当复杂和多变的系统，从订单、欺诈、通知

将 DevOps 运动中的团队拓扑与领域驱动设计社区的上下文映射相结合，可以深入了解软件工程团队之间的潜在摩擦接触点。

谷歌工程主管乔·林奇的文章，获得SOLID原则作者鲍勃大叔点赞转发的文章：作者推荐将SRP视为DDD原则的自然结果：跨DDD限制上下文共享的模型是不安全的。

“关键系统启发式”，又称“批判的启发式扫描”或“CSH”，是基于实践哲学和系统思维的反思性实践的框架。CSH的基本思想是支持边界批判，也就是批判性地处理边界判断的系统性努力。边界判断决定了哪些经验观察和价值考虑是相关的，哪些被排除在外或被认为不太重

尽管微服务具有各种好处，但似乎也有许多新的复杂性和并发症。我最近经常遇到的一种情况（并没有找到很多很好的资源）是删除数据。考虑一个简单的例子：有三种服务：Product 服务，管理与所提供的产品，Order 追踪产品购买服

Tomasz Jaskuła 是巴黎软件咨询公司 Luteceo 的首席技术官和联合创始人。Tomasz 拥有 20 多年作为开发人员和软件架构师的专业经验，曾就职于电子商务、工业、保险和金融领域的多家公司。他主要专注于创建能够提供真正业务价值、与战略业务计划保持一致并提供具有明显竞争优势的

我经常阅读有关领域驱动设计如何过于复杂或过度杀伤的评论。然后还有其他新的 DDD 想要应用它，尤其是技术模式，无处不在。所以问题是，你应该使用领域驱动设计吗？答案在中间的某个地方。 大型系统首先，让我定义一些我将在这篇文章的其余部分中

我们将设计一个基于经典遗留应用程序的进化事件驱动系统，类似于在世界各地的许多组织中可以找到的系统。这个练习将向我们展示事件驱动架构的潜力。 消息驱动与事件驱动区别让我们考虑两个需要通过信号相互传递信息的松散耦合组件。在这两种范式中，组

“来自事件的状态”假设一个现有的事件流，不管它是如何产生的，并从中预测状态。没有新事件添加到流；“作为状态的事件”是关于作为唯一事实来源的事件。换句话说，新事件被添加到流中，但它们受业务规则的约束，这些规则依赖于先前的事件作为它们的输入（而不是状态作为输入）。现在我们应该如何

在软件工程方面，我们的愿景是让 BBC 以其工程和内容而闻名。为此，我们必须进一步发展 BBC 作为产品和技术公司的理念。我们的资产中有数百个微服务，所以我们有跨学科团队负责每一个。我们尽最大努力在赋予每个团队权力和确保我们全面进行高度协作之间取得平衡。我们希望 BBC 以其

需要其他团队合作是很自然的。等待他们或依赖他们为您提供一些东西可能很诱人，发生这种情况是因为他们拥有您需要工作的区域。例如，您可能需要一个团队将一个字段添加到他们的 API 中。或者您可能需要它们为您构建新的 API。有时，如果没有这些更改，您就无法交付所需的内容。这是一个组织陷阱。

Vladik Khononov 是《学习领域驱动设计》一书的作者。在这一集中，我们深入讨论了领域驱动设计 (DDD) 和 Vlad，首先分享了为什么理解业务领域在软件工程中至关重要，以及 DDD 如何帮助在领域专家和软件工程师之间建立共同的理解。Vlad 随后解释了 DDD 中的两个重要设计

API 设计的核心是有效的沟通，不仅是开发人员之间的沟通，还包括将产品思维、业务和技术融为一体的沟通。James Higginbotham 是《Web API 设计原理》的作者和执行 API 顾问。James 还推荐 API Design-First 方法——一种快速且轻量级的基于结