eventSourcing将事件建立为系统中唯一的事实来源。通过采用动态一致性边界DCB，eventSourcing提供了高度灵活的事件使用，允许随着时间的推移出现最佳的设计。事件流系统事件流系统通常.

在不同的团队中编码多年后，我想我现在终于可以向自己解释，为什么我们需要或不需要用模式和抽象构建的 "聪明的 "代码。最近我一直在阅读关于团队组织的各种方法（尤其是“团队拓扑”）以及如何组织团队以减少认.

Margaret-Anne (Peggy) Storey和Abi Noda是最近发表的ACM论文 "DevEx: What Actually Drives Productivity "的合著者。在这一.

敏捷和设计思维已经针对同一个问题提出了两种不同的解决方案。 设计思维首先寻求学习。 另一方面，敏捷寻求先构建。 敏捷团队成员将设计思维视为 BUFD（Big-Up-Front-Design）。他们提倡.

越来越多吹捧单体的炒作如同当初炒作微服务一样愚蠢。当我开始从事技术工作时，世界被GoF四人帮设计模式所困扰。现在，我们被服务架构SOA所迷惑。这些模式往往是陷阱，掩盖了真正的实践经验。你应该从微服务中.

Amazon 的 Prime Video 团队发布了一个相当出色的案例研究，说明他们决定放弃无服务器的微服务架构，并用单体取而代之。此举为他们节省了惊人的 90%(!!) 运营成本，并简化了系统。真是.

任何给定软件项目的成功都可以归结为一个相当简单的定义或规则：我们需要构建正确的东西，我们需要正确构建这个东西。这是一个非常抽象和简单的定义，即使不是原始的定义。然而，这是一个很难争论的问题。做正确的事.

从 devops 到平台工程的转变可能是变革性的。以下是实现这一飞跃的原因和内容。Devops 工具和实践，包括使用 CI/CD 进行部署、将基础架构配置为代码以及管理容器化系统，所有这些都使 IT .

ESB意味着一个中心团队，这往往成为一个瓶颈，因为他们在ESB里实现了业务逻辑。而PE只是提供了一个平台，由开发团队自助式使用，通常也利用SaaS。中央ESB的问题在于它总是由第三个团队管理。因此，当.

逆康威策略不太可能在特定规模和稳定性的现有社会技术系统中发挥作用。在远程公司和分布式团队中工作的可能性更小。简而言之，在现有的社会技术系统中，逆康威机动的执行具有挑战性，而且不太可能产生预期的结果。逆.

“交付日期”是最糟糕的瀑布式思维。具体交付什么是我们在工作中学习如何交付。每天交付。逐步改进，先做最重要的事情。大批量思维是一种反模式！问：很多年前我有过一次艰难的交货日期。 一个系统正在进入挪威山顶.

如果您发现自己在担任产品负责人时难以做出有效的决策，或者您在想出一个有凝聚力的产品策略时遇到困难，那么您并不孤单。也许您的直接下属不断向您寻求指导和方向，但不确定该走哪条路。听起来有点熟？如果是这样，.

我与Nick Tune共同撰写了这篇文章（Nick 博客上的文章），基于我们个人的经验以及与客户合作的经验和教训。它涉及我们正在积极编写、开发和咨询的几个主题，特别是：架构现代化、团队拓扑 - 支持团.

虽然我在 Spotify 工作了大约 8 年，但我并不熟悉每个领域的运作方式，而且我有自己的偏见、偏好等。而且情况会发生变化敏捷 > ScrumSpotify 早期主要采用 Scrum（在我的时间之前.

低语境（Low-context）文化是明确和直接的信息，人们相互告知真实的情况。因此，只需要少量的语境上下文就能理解低语境的交流，因为你需要知道的大多数东西都被清楚地表达出来了。人类学家 Edward.

让我们帮助您开始发展和扩展您的组织。本指南面向创始人、PM 和高级领导者（CTO/CPO/CRO/CMO）。什么是增长？增长是围绕用户获取的功能，也是保留和货币化的功能。追求客户成功是产品和营销的逻辑.

企业可读性是一种艺术，它使那些没有直接参与的人更容易理解任务及其结果。我将帮助你了解为什么这是一件需要注意的重要事情，以及如何利用它来帮助你的职业生涯。简介首先，一些定义。我使用 "公司 "和 "企业.

敏捷会帮助你高效地建造东西，但你最终可能会在建造错误的东西时非常高效。产品迭代的短反馈循环是敏捷如何比瀑布格式更不可能构建错误的关键所在，反馈是敏捷的燃料。与您的客户、用户和/或利益相关者交谈。与您的.

Scrum承诺要解放开发者：它是对定义许多瀑布项目的命令和控制做法的彻底转变。Scrum是关于自我管理的团队和可持续的步伐。它应该是一种 "高贵的体验"（Agile Software Developm.

架构有时很难——人们不断提出一些新想法，这些想法很快成为主流的“做事方式”，微服务是最新的趋势，现在是我们剖析这个想法并找到正在发生的事情的真正根源的时候了。在微服务的核心，我们被告知我们会发现……..

在过去的几年里，我对多个正在进行数字化转型的产品团队进行了架构审查：大多数团队都按照微服务架构构建产品，他们使用基于微服务的架构的意图是正确的——更快的开发、更好的可扩展性、更小的独立团队、独立部署、.

团队拓扑结构不是一个 "模型"，而是一套鼓励新兴（emergent涌现）行为的约束。反对意见：团队拓扑是建立在软件如何生产和应该生产的模型之上，并提供一种模式语言、一个框架、一组与该模型一致的约束。模.

拉伸系统法则（ Law of stretched systems）：每个系统都被拉伸以在其能力范围内运行；一旦有一些改进，例如以新技术的形式出现，就会利用它来实现新的活动强度和节奏。您可能已经注意到，.

来自“UNC计算机科学”的不幸消息——Fred P. Brooks，该系的创始人和长期主席几小时前去世了。网友：1、20世纪60年代，布鲁克斯在IBM管理System/360和OS/360项目，这是大.

长期以来，我一直在想，通过一个将员工视为组织提供的能力的消费者的视角来看待所有的组织是否有价值？然后问 "你的组织方式如何提供这些能力？"这可能看起来有点玄，所以这里有两个例子： 跨国集团Acme公司.

平台架构师需要一个强大的 "产品思维"，而企业架构师需要一个 "组合思维"。区别在于你要迎合谁，以及如何管理?平台架构（包括内部平台）需要大量的关注，纯粹的意志和努力才能真正成功。你必须为严格定义的受.

Spotify 工程师必须快速试验、学习和启动功能。通过具有所有必要技能的跨职能团队来实现速度，以高度自治地发布功能。这是他们对速度质量的定义：“快速将创意转化为产品并进行实验，以改善用户体验、开拓新.

1、有效的软件是与业务挑战相一致的软件我们所说的一致，是指软件从领域中借用正确的术语，正确阐述业务的关键概念，并尽可能少地避免技术问题带来的意外的复杂性。2、康威定律不是一个可以选择不接受的选项。它的.

领域驱动设计在康威定律中发挥作用，帮助定义组织结构：    因为 DDD 的一个关键部分是识别BC：BoundedContexts。    BC一个关键特征是它有自己的UL：UbiquitousLan.