架构的持续演进，是系统和团队成长和成功的关键。将有几篇文章来分享一些想法。上一篇（链接），讲了持续演进架构的组织模式，这一部分，讲讲总体机制设计。

聊一下架构工作在团队中的组织模式。主要是各个架构角色的分工和协作模式。

蓝图与拼图，是类比于分析和解决问题的两种过程模式。联系到前面的文章¹，可以说也是“驱动”的两种模式。

之前就“驱动”、“领域驱动”这些主题做了一些讨论，现在看看作为一种架构设计的驱动技术，“领域驱动”有何特点。

DDD就是领域驱动设计，这里想要分别谈一下DDD里面的三个D。兼谈一点我们实际的开发团队的DDD实践活动，我们的收获和教训。

之前¹谈到“驱动”这个概念。说“驱动”讲的是拆分问题的单位，现在尝试讨论下，什么样的东西，适合用来作为这个驱动者，也就是说，什么样的东西，适合用来拆分问题。

领域驱动、测试驱动、风险驱动；面向对象、面向组件、面向服务。这些说法我们都已经很熟悉了，大家研究的重点往往是其中的那个名词。名词是关键没错，但那已经说得够多了。今天来聊聊其中的动词，“驱动”与“面向”。

之前有思考过研发团队发展的三个要素¹。

在敏捷环境中，进一步思考了三个要素和它们之间的关系。

微服务的划分方法，常见的是两种，按业务能力和按子域¹。

Linus说： “烂程序员关心的是代码。好程序员关心的是数据结构和它们之间的关系。”