AdHoc需要在快速发展的工程团队中推出新的领导层，需要重新构想如何沟通，以及信息将如何在这个新的领导层中流动。   松耦合和高.

  连续架构六大原则 连续架构不是一种架构方法。这真的是一种心态，几乎是一种工作方式，一种思.

我想写下为什么从一个全新的项目开始使用微服务通常是一个坏主意。 时机已到，这正是我将在本文中讨论的内容。 微服务变得越来越自然，我们几乎感觉自己.

本文《Agile as Trauma》指出敏捷的本质是反动的（reactionary：保守、落后、反动）。敏捷就像任何概念一样，必须适应和学习，将产品管理和.

改善交付时间应该是每个组织的目标。阻碍交付流程加速的一个主要减速器是组织中的不同团队传统上一直在孤岛中工作。为了解决这个问题，在大多数情况下会出现一个简单的.

我知道微服务的话题已经被反复讨论过，我只是想根据我在这种设计 Web 应用程序的方法方面的经验，将我的经验加进去： 很多人认为微服务.

美国组织理论家罗素·阿科夫 (Russell Ackoff) 说：“一个系统不仅仅是其各部分的总和；它是一个不可分割的整体。当它被分解时，它就会失去其本质属.

Nick Horney 是《VUCA Masters》的作者和 Agility Consulting 的创始人。在这一集中，Nick 分享了他在领导敏捷性方.

Matthew Skelton与 Manuel Pais 合著了《团队拓扑：组织业务和技术团队以实现快速流程》一书，这是一篇开创性的文本，讲述了如何围绕软件.

需要其他团队合作是很自然的。等待他们或依赖他们为您提供一些东西可能很诱人，发生这种情况是因为他们拥有您需要工作的区域。例如，您可能需要一个团队将一个字段添加.

本文列举了一些可以应用于软件开发的最流行的规则和原则。对于每条定律，我们将快速讨论其主要命题，然后探讨如何将其应用于软件开发。   .

2010 年代是软件工程史上的一个转折点。在本世纪初，Eric Ries 通过 .

新型产品技术团队模型简述： 没有孤岛，团队专注于了解客户的问题和市场挑战（环境），并由此发现和塑造他们应该如何构建和发展他们的产品（.

是业务决定技术？还是技术决定业务？是人决定IT，还是IT决定人？这是康威定律与敏捷的区别： 一位叫 .

随着时间的推移，不同的人以各种不同的方式阐明了康威定律。这是我最近在阅读康威定律文献时发现的变化的概述。 Melvin Conway对康威定律的原始定.

假设有一个农业机械零件的批发商。他们建立了一个 B2B 网上商店，供经销商和机器维修公司订购。在他们无处不在的统一语言与术语中，订单代表了这个自动化流程：它.

领域驱动设计的主流思想是关于实体、值对象、聚合、存储库、服务、工厂……各种技术模式。因此，大多数人认为他们不需要领域驱动设计，因为这对他们的领域来说很复杂。.

当前人们对大脑自身的认识深入促进人工智能和认知科学等方面发展，仿真人类的大脑思考模型称为启发很多创新方法研究的源泉，例如人其实是神经元交互聚合的产物，人类群.

当您公司的整体Web应用变得太大而脆弱时，部署变得缓慢而令人恐惧。因此，作为一家软件公司，您已决定遵循许多其他公司所采用的方法——将这个整体/单体架构拆分为.

很多团队没有专职的架构师，但是实际上有一些角色参与了架构决策，根据康威定理，组织架构决定了技术架构，如果管理者确定了系统的体系结构，那么他们实际上就是其架构.

Uber核心平台技术最初押宝Thrift和Mesos，这种两种技术后来分别被gRPC和Kubernetes主流技术替代。 当初您做出技术路线决策的 .

1.康威定律 也称为：“您将承载组织结构。 ” “任何设计系统的组织都将产生其结构是组织通信结构副本的设.

将我们的软件分解为模块时，我们常常忘记重要的社会方面。设计如何影响团队，可能使他们相互竞争。一个具有韧性和可持续性的系统需要和谐。 谚语“好围墙造就好.

软件设计的目标是创建适合人类思维的块或切片。软件一直在增长，但人类的思维会达到极限，因此，如果要继续进行软件更改，我们必须进行切片和分块。 这意味着软.

敏捷的软件公司组织结构最好能映射到业务领的结构，公司组织结构不要映射到技术。 DDD创建了一个从领域映射到软件技术的架构。 如果有界 .

我想明确指出我不是反微服务者，我将服务合并回到整体(单体/Monolith)中并不是为了摆脱微服务，目的是实现“大小正好”的整体。我正在做的事情是解决我团队.