限定上下文BC

为了对该主题进行有意义且细微的讨论，我们首先需要定义智能。

使用微服务意味着从松散耦合的服务创建应用程序。该应用程序由几个小服务组成，每个小服务代表一个单独的业务目标。在复杂

电子邮件唯一性检查属于业务逻辑，是应该放到领域模型User类中？还是UserController中？这里有领域模型完整性和纯度的抉择： 领域域模型完整性是指您的域模型包含所有应用程序的域逻辑。按照这个依据，电子邮件唯一性检查属于领域逻辑，领域模型应该包含所有的领域逻辑，放入U

Apache Kafka已成为跨微服务异步通信的领先平台。它具有强大的功能，可让我们构建健壮的，有弹性的异步体系结构。同时，我们需要预料到潜在的陷阱。如果无法提前识别出可能（不，将要发生）的问题，将使我们面临易于出错和数据损坏的系统。在本文中，我们将重点介绍这样的陷阱：处理消

尽管微服务中的“微”一词表示服务的规模，但它并不是使用微服务的唯一标准。当团队转向基于微服务的架构时，他们旨在提高敏捷性以及自主且频繁地部署功能。很难确定这种架构风格的简单定义。我喜欢

有些人说设计模式已经死了。真愚蠢！ “设计模式”书籍是我们行业中出版的最重要的书籍之一。对于所有专业程序员来说，其中的概念应是基本知识。 设计模式就像现实生活中的谚语：这是开放了其他人的经验。 假设需要调用10种不同类型的设备，然后再打开它们，我会创建一个De

将大型复杂系统模块化为更小和更易于管理的部分是一种最佳实践，这不仅是为了降低每个部分的认知负担，而且还可以降低团队的独立性和运营弹性。棘手的一点是如何划定边界，使整个系统稳定而可持续。带有边界的上下文是领域驱动设计的一种方法，业务领域的语言用作指导，还有另一种方法是从业务模型定义的功

汇丰商业银行的数据设计师Narasimha Reddy本周在Live上发表讲话，解释了该组织如何通过从65个关系数据库迁移到MongoDB的一个全球实例中来简化其应用程序交付方法。汇丰银行是全球知名度最高的银行和金融服务组织之一，业务遍及60多个国家，为4000万客户提供服务。但是，

多年来，Facebook已从一种基本的Web服务器体系结构演变为一个复杂的体系结构，其中包含成千上万的服务在后台运行。扩展Facebook产品所需的各种后端服务并不是一件容易的事。而且发现我们的许多团队正在构建具有重叠功能的自定义分片解决方案。为了解决此问题，我们将Shard Manager

我们如何才能快速地从整体变为微服务？无法回答这个问题。首先，“迅速”就在窗外。你一个月都没弄糟。您将不会在一个月内修复它。其次，您希望从微服务中获得一些您目前无法获得的好处。那有什么好处？微服务不是重点。拒绝了这个问题之后，我将继续回答。在我无法解释为什么无法快速更改微服务之

在SummerSoC 2020上，我介绍了我的

许多软件开发人员会很快告诉您： “我们很敏捷” “我们认为工作软件胜于全面的文档” “价值在于对话” “代码就是文档” “测试是文档” 代码是事实，而不是全部事实正如

事件建模的创始人Alberto Brandolini说：数据是在有界上下文之间流动的，而行为是特定于某个有界上下文方式的。如果围绕数据划分微服务边界将导致分布式耦合。这不是我最喜欢的方式。（banq注：按动词如行为或事件寻找上下文之间边界，以此划分微服务边界，不是根据对象的数据属性，一个对象

您所做的事情越复杂，即使只是将其结构化，是一种建设性的复杂性(如数据表结构设计，DDD聚合设计等，关联关系不能太多，虽然这是一种结构化关系，但是如果有很多1:N和1:2甚至N:N关系，则会复杂化)。复杂化会让排斥您的人也就越多。简单化就是无障碍。 我可以原谅建设性的复杂性：抽

LinkedIn消息平台现在存储了价值17年的消息（使用17年的不同产品功能创建），并且发送的消息数量一直保持不变往上走。最初，这些消息看起来很像电子邮件。现在，他们看起来更像是聊天，带有主题，群组对话，表情符号，没有主题行。支持该消息传递系统的代码已经过更新，变得越来越复杂，但是多