限定上下文BC

衡量一个人或团体的意识形态化程度的一个标准是，当你陈述一个事实时，他们会问 "你这是什么意思？" 对于智力上诚实的人来说，事实本身是优先的。他们通常是确认事实并相信事实，在这之前是不会立即思考这个事实可能支持什么结论。

我们都喜欢建立绿地新项目。 但不可避免的是，开始一个新的项目需要与商业利益相关者进行大量的会议，以确定初始需求和典型的数据模型。这些都是......不那么有趣的。 当这些会议之一发生在高碳水化合物的午餐之后(米面等精致碳水导致胰岛素

这是一个关于如何被迫放弃继承和面向对象编程的故事，作者仍然怀念它很长一段时间。为什么五年后的今天，作者还是认为继承在大多数情况下是一个较差的选择。 Rust 和 Go 等新兴语言非常强烈地反对继承，许多工程师似乎也同意这一点。这就是继承的终结吗？<

验证是区别于业务规则的定义。 本文提出了软件开发中验证的定义：介绍了我目前是如何区分验证和业务规则的。我发现这种区分是有用的，尽管这也许是一个因果关系颠倒的例子。我的定义是这样的：

使用Clean清洁架构注意：请勿将系统直接连接到外部系统！需要通过适配器转换或验证： 在企业应用中，我们经常需要与第三方系统集成。例如，如果我们有一个订购系统，我们可能需要将其与企业资源规划系统和快递系统集成。在工业自动化领域，我们可能需要与传感器

几个世纪以来，对创造力的探索一直吸引着不同领域的思想家，产生了丰富多样的观点。 一些最有影响力的观点来自查尔斯·桑德斯·皮尔斯、吉尔·德勒兹、克里斯托弗·亚历山大和大卫·博姆的哲学基础。 尽管他们的工作背

Martin Fowler的同事Matthew Foster描述了团队拓扑和领域驱动设计如何帮助组织扩展技术架构和团队结构，从而显着提高开发速度。 模块化架构能改善软件交付吗？是的！但要注意一些问题。

当你记录一个系统的不同部分以及这些部分之间相互作用的各种方式时，时序图/序列图( sequence diagram)才会真正发挥其作用。 时序图/序列图描述了系统内的操作，并映射出消息的发送内容和时间。

在我研究生涯的早期，我曾有机会与世界上一些最优秀的系统研究人员一起研究一些非常有趣的系统设计。 研究工作的乐趣之一在于研究人员（尤其是 SOSP/OSDI 社区的研究人员）在提出新颖而实用的设计方案时所采用的特殊过程。这一设计过程的特点可以

本文介绍将现有单体应用程序迁移到微服务中，如何重构数据库？ 数据库重构模式可以通过多种方式重构关系数据库（例如 PostgreSQL）以优化基于微服务的应用程序架构的效率。如前所述，数据库是结构化数据的有组

Alan Moore （Aladdin 首席架构师、技术研究员和董事总经理）描述了贝莱德在资产管理中使用领域驱动设计DDD，以及我们如何使用它来定制、扩展和调整 Aladdin 以满足客户的需求。

群体和社区的规则的关键特征是，个人和组织（以及机器）有时会打破规则。 这很明显。它一直在发生。只要看看你的周围。想想我们花了多少时间和精力去预测、检测和制裁违规行为。这就是为什么我们有监管机构、警察和监狱。还有合规部门。还有无休止的数据清理活动。<

作为软件开发人员的培训师和教练，我看到模块化软件设计（例如，面向对象或微服务）对人们来说是一种难以理解的技能。 在许多不同的模块化层面（方法和功能、类和模块、包和组件、流程、服务、服务器、系统和系统的系统），用许多不同的方式来解释它，这并没有什么帮

如何区分产品基础设施和技术基础设施 ： 技术基础架构--不需要构建业务/产品背景，主要由开发人员使用。它不会立即影响用户体验，并且可以包含在一个特定的行会中。 产品基础设施——影响用户体验或有产品需求。 平台组负

与许多其他产品一样，WeTransfer最初是一个小型单体应用程序，但很快就变成了一个拥有太多责任和贡献者的大型单体应用程序。发布新功能变得越来越困难，技术债务也在增加。这就是为什么我们开始将一些核心逻辑分离到不同的服务中。其中一个模块是计费逻辑。