限定上下文BC

当您公司的整体Web应用变得太大而脆弱时，部署变得缓慢而令人恐惧。因此，作为一家软件公司，您已决定遵循许多其他公司所采用的方法——将这个整体/单体架构拆分为微服务架构。这个迁移旅程可能漫长而艰难，潜伏着许多错误的踩坑，以及您想要避免的路径。我自己经历过，也许我的经验可以提供帮助。

全球ddd社区做出主要贡献的人员名单(按Twitter名称排列)： @ericevans0 创建了DDD @ziobrando 发明了事件风暴建模方法。 @ntcoding 发明使用画布canvas 映射有界上下文方法。 @swardley 发明War

该文是事件风暴创始人Alberto最新文章，谈论了DDD中有界上下文BC划分与团队组织划分方式是两种不同目标方式，不能简单一个DDD有界上下文对应一个微服务对应一个团队，而是在对业务知识深入理解学习过程中随着BC或微服务动态调整团队大小，不可能一劳永逸在项目开始之初就能确定好团队组织结构。<

例如，假设您是一家 SaaS 企业的创始人/首席执行官，其主要产品是一个 Web 应用程序，可让用户存储和操作他们的照片。您正在查看第二季度的收益，并意识到您目前的收入流可能还剩下六个月的运营费用。在过去的五年中，您以直觉和最佳实践相结合的方式经营公司。到目前为止，这已经奏效，但现在

在前面帖子如何绘制Wardley地图？中，我们假设了一个SaaS 企业的创始人案例，为了挽救即将倒闭的公司，你需要进行理智的分析，理顺你公司的战略设计存在什么漏洞。这可

相关性不代表因果关系，但是没有相关肯定没有因果吗？诺贝尔奖获得者卡尼曼也有范常识错误的时候：《思考，快和慢》是由诺贝尔经济学奖获得者丹尼尔·卡尼曼（Daniel Kahneman）于2011年出版的畅销书。主要论点是两种思维方式

一旦您拥有多个微服务，就很难在一张图上显示所有微服务。建模方式有几个选项： （1）对图进行分区：显示每个单个的领域，有界上下文映射/业务能力等是一种很好的方法。 （2）也可以集中于单个微服务及其传入/传出耦合。例如：

转移到微服务不仅涉及将整体应用程序重新包装到容器中。架构上存在根本差异，影响到从传输数据到故障恢复的所有方面。无法解决这些差异可能导致可扩展性受限，性能下降以及意外中断。您的团队已决定将您的整体应用程序迁移到微服务架构。您已经对业务逻辑进行了模块化，对代码库进行了容器化，允许开发人员

著名敏捷教练GeePaw Hill认为：SAFe框架破坏了实现敏捷性的任何可能性。这是在做最不敏捷的事情。我认为这是敏捷运动中的最终会失败的一个案例。 网友意见：尽管您可能会发现SAFe令人沮丧，但我仍然认为它比CMM更好。 因为SAFe并不是敏捷团队

用户故事映射通过一步一步的流程直观地显示用户浏览我们软件的过程，并在此过程中创建各种用户故事。与简单的积压订单相比，用户故事图在产品环境中增加了位置和移动的维度，使您可以先进行图绘制，然后浏览产品的整个用户空间。借助用户故事图，您可以在上下文中看到整个图景，而线性积压则不会那么多。我

当业务流程跨多个系统流动时，集成要求对于任何项目的成功都是至关重要的。作为业务分析师，我们有责任了解端到端的业务和系统流程，并在需求收集流程中记录下移交。收集系统之间集成需求的系统方法将确保系统之间以及业务流程之间的平滑交互。下面的“集成需求分析框架”提供了一种系统的方法来记录集成项目的需求

有效的软件团队对于任何组织持续不断地创造价值至关重要。但是，如何根据您的特定目标，文化和需求建立最佳的团队组织呢？2012年，音乐流媒体服务

认知神经科学的渐进模板： 这是一个系统 这是两个系统 两个系统实际上是一个系统 有两个但它们广泛地且动态地交互作用 我们不知道运作方式 DDD建模认知的渐进模板： 这是一个领域 这是两个领域 两个系统实

开发人员喜欢使用首字母缩写词来说明“良好做法”（KISS，DRY，SOLID等）。通常，他们传达的想法非常容易掌握。DRY是dont-repeat-yourself不要重复自己意思，其目的是更好地管理复杂性，但是通过以这种基本/教条的方式应用DRY，我们发现复杂性有所增加。D

您如何构成一个DDD聚合？对我而言，聚合设计涉及对不变性的理解。不变是必须始终保持一致的业务规则。了解不变式将指导您的聚合设计。聚合是基于不变性和一致性定义边界的另一个示例。 送货案例我将使用的示例是“Shipment”的概念。您可以

英国航空公司TUI用来办理登机手续的软件出现编程错误，导致去年7月三趟航班的飞行载荷计算错误，这可能是一个严重的安全问题。根据英国航空事故调查局（AAIB）周四发布的报告[