用一个数字形容你自己（用个十百千思考DDD）

用一个数字形容你自己（用个十百千思考DDD）业务能力扩展和复用，其中涉及到业务领域，上下文和系统边界的划分，到底如何划分？单体向微服务转型，到底怎么拆分微服务和中台呢？DDD 就是划分业务领域，限界上下文和系统边界的方法，指导完成应用拆分，微服务和中台设计。DDD 虽然在 2003 年提出来，但是在微服务和中台没有出来前，一直没有火。时代不对，即使 DDD 这个“羽毛”也飞不起来。随着互联网和电商业务的高速发展，很多企业技术升级频率很快，并成功应对了海量高并发的业务场景。可以预见技术（如性能和可扩展性等）将不会成为制约业务发展的短板。现在和未来企业更多是将关注点放在业务能力设计和实现上。在新的互联网业务模式下，很多企业开始提升技术能力，将架构从单体转向分布式和微服务。这是因为集中式单体架构业务功能庞大和复杂，业务逻辑耦合高，开发者宁愿增加代码而不愿意修改遗留代码，避免出现不可知的bug，最终导致可读性差，恶性循环。与此同时，企业开始

商业模式或者软件设计模式正确，不代表必然成功。你需要把时间轴纬度，也就是“趋势和方向”加入到思考系统中。具体怎么做，可以用“个十百千思考法“。时代是千位，战略是百位，治理是十位，管理是个位。DDD (领域驱动设计)是 Eric Evans 于 2003 年提出的一种软件设计方法和理念，里也包含了战略、战术、治理和管理等概念，那么“个十百千思考法”和 DDD 关系是什么样的呢？本文将用“个十百千”来思考 DDD，为大家揭开这层迷雾。

1. 什么是个十百千思考法？

千位的重要性，远远地高于百位、十位、个位。雷军曾说过：站在风口上，猪都会飞。说明了企业成功的关键是顺势而为。理解趋势，那么选择如有天助，而不是胜天半子。

百位是战略。战略不对，就是带领企业或团队在死路上狂奔。比如在科技含量高的行业，创新是一个战略。飞猪理论中我们可以直接把猪扔到风口，也可以创新地给猪装上翅膀，猪就会飞的更高更快。

十位是治理。此时就要思考组织与团队的事情。得选出谁是老大，谁是掌舵人，谁是维护翅膀的，和给猪喂食的人等。只有层级分明，结构稳定，大家才能同心协力，保证猪能够在风口持续地起舞，不至于掉下来。

管理是个位。当时代、战略、治理都趋于稳定时，管理就显得非常重要了。管理是解决人与事的各种问题，让人心齐，事能成。

时代是千位，战略是百位，治理是十位，管理是个位。它们的重要性依次呈数量级递减。越是变化的时代，前面越重要；而越是稳定的时代，后面越重要。Eric Evans 在领域驱动设计中也提及了战略、战术、治理和管理等概念，那么在 DDD 中，或者想要成功的 DDD 中的“个十百千”是什么样的呢？

2. 数字化转型是千

有企业研究指出，在中国成功实现数字化转型公司，业绩复合增长率是尚未转型的同行企业的五倍之多。美国风险投资机构 Work-Bench 在 2018 企业软件调研年报中推论：以微服务为代表的云原生技术，是帮助企业实现有效数字化转型的唯一技术途径。

随着互联网和电商业务的高速发展，很多企业技术升级频率很快，并成功应对了海量高并发的业务场景。可以预见技术（如性能和可扩展性等）将不会成为制约业务发展的短板。现在和未来企业更多是将关注点放在业务能力设计和实现上。在新的互联网业务模式下，很多企业开始提升技术能力，将架构从单体转向分布式和微服务。这是因为集中式单体架构业务功能庞大和复杂，业务逻辑耦合高，开发者宁愿增加代码而不愿意修改遗留代码，避免出现不可知的bug，最终导致可读性差，恶性循环。与此同时，企业开始提升业务复用能力，从业务重复建设到中台建设来实现能力复用。

业务能力扩展和复用，其中涉及到业务领域，上下文和系统边界的划分，到底如何划分？单体向微服务转型，到底怎么拆分微服务和中台呢？DDD 就是划分业务领域，限界上下文和系统边界的方法，指导完成应用拆分，微服务和中台设计。DDD 虽然在 2003 年提出来，但是在微服务和中台没有出来前，一直没有火。时代不对，即使 DDD 这个“羽毛”也飞不起来。

但是话又说回来，DDD 也是适用于单体架构帮助业务能力划分。

3. DDD 的原则和战略设计是百

DDD 提倡通用语言、聚焦核心域、协作共创和持续建模。这些原则是为了更好地服务业务，从业务领域出发，来驱动模型设计。DDD 模式包含了业务和技术，从问题域到领域模型再到最后的设计和实现，贯穿了整个软件全生命周期。

战略设计是根据用户旅程和业务场景，从事件风暴或者其他建模方法开始，提取实体和值对象，分析出领域模型和聚合，然后划分限界上下文，建立领域模型的过程。在这个过程中，聚合和限界上下文提供了两个层次的边界，解决了微服务业务和应用边界难以界定的问题，可以指导我们微服务的划分和设计。清晰的微服务边界就更容易适应业务的快速变化，容易地实现微服务架构的演进，自然就能快速地响应变化频率较高的前端业务需求。

4. 团队组织是十

下图团队的定义出自我的同事笪磊，从业务引导力，架构决策力，技术实施力和质量把控力的维度显示出组织团队的协作沟通并在 DDD 整个过程中的产出。

在百位里面我们说到了 DDD 帮助我们解决了业务和系统边界的问题。在传统软件开发过程中，业务架构决定了组织架构，组织架构进一步决定了系统架构。根据 1967 年的康威定律，组织沟通方式会通过系统设计表达出来。对于复杂的，需要协作完成的系统开发，沟通是需要持续提升的事情。在团队内部进行频繁的、细粒度的沟通。对于团队外部，定义好接口，契约，只进行粗粒度的沟通。线型系统和线型组织架构间有潜在的异质同态特性，团队分成怎样的结构，架构就会成怎样的。在 2015 年 James 提出了逆康威定律，应不断演进组织或者团队结构，从而匹配并促进所期望的得到的架构。这样，在理想的情况下，技术架构将于业务架构显示出同构性。

不管是团队的定义，康威定律还是逆康威定律，我们都能看出组织和团队的重要性。组织和团队是战略的落实者。层级分明的沟通方式，组织结构稳定并持续随业务和系统演进，大家才能同心协力，保证 DDD 在战略和战术上的实施。

5. DDD 战术设计是个

战术设计是根据领域模型和限界上下文完成微服务设计的过程，识别和设计微服务，建立逻辑和物理的分层和依赖关系。设计微服务内的实体，值对象，建立领域模型与代码之间的映射关系。这样就能指导团队进行微服务或者中台的开发和测试了。当数字化转型、DDD 原则和战略设计、团队组织都趋于稳定时，战术设计的管理就显得非常重要了。其解决团队中人与战术实施的各种问题，让团队能坚守 DDD 的原则，做好代码与领域模型保持一致。这样数字化，微服务，中台等才能成功。

6. 总结

企业在进行数字化转型的时代中，面临着业务种类繁多，业务高度依赖的问题。微服务和中台是解决这些问题的有效技术手段。DDD 可以同时指导微服务设计和中台业务建模。数字化转型是千，DDD 的原则和战略设计是百，团队组织是十，DDD 战术设计是个。越是变化的阶段，前面越重要；而越是稳定的阶段，后面越重要。高位确定时，低位重要性凸显。专注提高低位能力时，也要关注高位变化。

DDD 的原则和战略设计就像是生产力，团队组织就像是生产关系，DDD 战术设计就像是生产工具。DDD 的原则和战略设计决定团队组织，有什么样的战略，归根到底便会有什么样的团队组织。同时团队组织也反作用于战略，对战略的发展具有巨大的影响。DDD 战术设计是 DDD 原则和战略设计发展水平的重要标志，DDD 在战术上搞烂了(如代码和模型不关联)，也就不能支撑战略层面了。

原文出处：https://insights.thoughtworks.cn/ddd-thinking/?utm_source=tuicool&utm_medium=referral