限定上下文BC

敏捷的软件公司组织结构最好能映射到业务领的结构，公司组织结构不要映射到技术。DDD创建了一个从领域映射到软件技术的架构。如果有界上下文是商店、仓库和财务，那么架构中最大的可模块化部门就是商店、仓库和财务，而不是“前端”和“后端”之类技术的东西。康韦定律（Conway'

软件设计的目标是创建适合人类思维的块或切片。软件一直在增长，但人类的思维会达到极限，因此，如果要继续进行软件更改，我们必须进行切片和分块。这意味着软件设计实际是人为人自己提供技术支持的过程（人类互助）。软件设计是人类关系中的一项练习(banq注：道德伦理也是一种人类关系)。 

好的代码本身就是最好的文档。在您要添加注释文档时，问问自己：“如何改进代码，以便不需要这些注释文档？” 改进代码，然后对其进行记录以使其更加清晰。 - Steve McConnell 众说纷纭：

将我们的软件分解为模块时，我们常常忘记重要的社会方面。设计如何影响团队，可能使他们相互竞争。一个具有韧性和可持续性的系统需要和谐。谚语“好围墙造就好邻居”描述了为什么我们的软件设计需要边界：不仅是解决问题并使其易于理解和管理的一种方法，而且还可以使您公司中的团队更好地相处并相互发挥最

我想明确指出我不是反微服务者，我将服务合并回到整体(单体/Monolith)中并不是为了摆脱微服务，目的是实现“大小正好”的整体。我正在做的事情是解决我团队的痛点。如果不能减少摩擦，我将不会花费太多时间（和机会成本）来提升，转移和重构旧代码。每次这样做，我都会冒引入新错误并破坏用户体

牢记业务上下文的技术决策建议，业务上下文是唯一的衡量软件质量的关键指标。如果有事情不对劲，软件工程师会感到不安。学生或初级工程师由于不熟悉编程概念而感到不安。渐渐地，我们对更高层次的抽象感到不安：我们不再会像当初因缺乏理解而烦恼，而是知道系统确实属于有害反模式时，会更加不安。

领域驱动设计是一种设计系统（通常是软件）的方法，该方法强调在域专家和系统构建者之间创建通用语言。著名的DDD原则包括使用

自从微服务变得流行以来，团队正试图将其单体划分为一组小型、独立且可高度扩展的微服务。从理论上讲，这通常看起来很容易。您只需要遵循领域驱动设计的关键原则，在您的应用程序中标识有界的上下文，并将每个上下文提取为微服务即可。通常，实现很快变得比看起来复杂得多。总是有一些用例需要来自完全独立

最喜欢的（微服务）语录：“对于想要跨服务实现事务的架构师的最佳建议是：不要！” - 书籍《软件架构基础》

如果在线销售产品是您业务的核心部分，那么您需要构建可扩展，灵活且快速的电子商务数据模型。诸如Shopify和BigCommerce之类的大多数现成供应商都是为每月销售几百万美元订单的小型商店而建，因此许多从事大规模工作的电子商务零售商开始研究创建定制解决方案。本文将研究您自己开始构建

您在图片中看到了什么？一块硬纸板？一

大多数问题和改进的最大可能性都属于该系统。试图从整体上理解系统，并考虑系统元素之间的相互作用。在系统中，所有事物都与某物相连。没有什么是完全独立的。这些联系和互动以及目的是系统的特征。更正式地讲，系统可以描述为：“一组元素

数据库是神话般的资源，我们已经滥用了它们。如果你拥有一个超级稳定安全的关系数据库，那么它就可能大包大揽，它就可能变成一把锤子，用来解决一切视为钉子的问题。在Tandem，我了解到支持公司业务的数据库是一个复杂而复杂的生物。它不仅需要提供对客户数据的访问，还需要在线DDL，高可用性，归

编排Orchestration和编舞Choreography是微服务架构中的两种交互方式。在编排Orchestration中，有一个控制器（“编排器”）控制服务之间的交互。它决定了业务逻辑的控制流，并负责确保一切按提示进行。这遵循了请求-响应范例。在编舞Choreograph

除了沉默，言语是我们谈话中非常重要的部分：-)。当涉及业务分析时，围绕定义存在许多挑战。项目词汇表应包含所有关键业务术语。让我们深入了解词汇表的常见挑战，并讨论如何克服它们。 问题一：最后才创建词汇表当团队

哲学思维最普遍的谬误都可以追溯到对上下文的忽视。什么是“内涵编程”？简单的答案是，使用基于内涵逻辑的语言进行编程。但这提出了另一个更重要的问题，即内涵逻辑是什么？逻辑学家一直致力于解决这个问题超过2500年。简短的答案是：内涵编程=逻辑的真值以及更一般的表达含义取决于隐式上下