【软件工程老方法为何能解微服务新难题？】10个QA快速认识DDD

微服务（Microservice）架构是近几年最红的应用程序架构，随着Web技术、云端架构、容器技术、DevOps流程等新兴开发技术和方法的成熟和普及，将传统大型单体式应用（Monolithic），拆解、重构成松耦合的微服务架构，成为更容易更新、快速发布、弹性扩充的云端原生应用，不只网络公司必用，更是现在企业IT现代化的新主流作法。

最知名的微服务实例之一，就是 Uber用了约2,200个关键微服务，才打造出支援全球超过700个城市，数千万名代雇驾驶，每天上千万趟行程的服务架构。Uber的微服务架构图就像是一张密密麻麻的网状星云图，呈现出数千个微服务相互关连后的复杂性。

复杂性就是微服务的价值和考验。微服务颗粒度越小（程式越小），就越容易针对单点爆量需求来扩充，功能异动的影响范围也越小，派送、部署的速度也能越快，但是，代价是颗粒度越小，微服务的数量就得越多，应用架构复杂性也越高，维运和管理的困难度都会跟着提高。

如何拿捏“适当的颗粒度和架构”成了微服务设计时的关键，也是最大的难题，可是，这个问题，一直没有标准答案，而且没有永远的答案，甚至10个架构师重构同一个应用，会有10套微服务架构。

早在2003年就问世的软件开发方法Domain-Driven Design（领域驱动设计，简称DDD），提供了一套可以系统性拆解微服务的方法论，也因此再度爆红，成了不少网络公司、企业用来解决微服务设计难题的新方法。

例如星巴克早从2015年推出的奖励忠诚度计划（Loyalty Program），隔年决定重新设计改版的新一代奖励平台，就是采用了DDD来设计，才打造出一个有能力处理十亿个事件的事件来源引擎，每秒API交易次数达到数千次以上。

台湾DDD社群核心成员整理了一份QA，可以快速认识这个老方法，一窥为何DDD能成为解决当红微服务架构难题的新解方。

 Q1：为何微服务当道，DDD重新受到重视？ 

 A  约2013、2014 年间，全球开始兴起一波将老旧系统转型为微服务的话题，当时 《建构微服务》（Building Microservices） 一书的作者 Sam Newman 更在书中开宗明义指出，微服务的设计是一连串现代软件工程的大成，涵盖了领域驱动设计、持续交付、按需求虚拟化技术（On-Demand Virtualization）、基础架构自动化、小型自主团队（Small Autonomous Team）、大规模系统部署。这些元素都有助于微服务建构和实践时的参考。

然而，多数人最关键的问题在于，试图将老旧系统拆解成微服务时，每个人对于拆解方式与系统边界的理解和定义，可能不一致。拆多了，要面临过度庞大分散式系统的系统通讯与监控的困难。拆得太少，又显得单一服务的职责太重、太杂，导致每次要修改部分功能，就得重新部署这支单一服务，受影响的范围过大。

在多种不同的微服务切割方法中，可以回归软件建模的根本面，场景驱动的业务表述，大部分商务应用软件，都循着一系列的应用场景描述开始捕捉，进而分门别类地，收归其职责画分到不同的模组底下，对应到分散式系统的开发部署角度上。开发者经常会发现，若能够从业务场景梳理不同服务与模组之间的关系，能够较为“有效”地管理跨服务之间沟通的复杂度与频率，也容易掌握服务与服务之间的上下游关系，进而能指导团队协作与组织间的协调。DDD是一种在软件开发生命周期前期，就能投入的系统建构指引，也因此，2003年就出生的 DDD，在2015年后再次重生，闪耀在各大产业面前。

 Q2：DDD、敏捷和DevOps三者有何不同？ 

 A  这三者完全不同，但彼此能够恰好地补足互相的不足。

简单来说，敏捷（Agile）是一种软件开发流程的方法，DDD是一种软件分析设计的方法，而DevOps则是开发团队和维运团队彼此为对方多想一点的文化。（国泰金控数数发中心云端技术架构师颜胜豪的观点。）

但是，有些企业导入敏捷时，会遇到企画端执行敏捷，但需求落地仍然按照既有IT开发流程，导致系统无法快速迭代，细究根因除了敏捷团队缺乏开发人员以外，也有系统架构耦合性过高、整体开发周期过长等问题。

身兼敏捷及DDD顾问的香港IT顾问Steven Mak对台湾社群分享时也提到，敏捷的导入，除了价值观和团队的建立外，系统架构和软件开发也是很重要的一环。ThoughtWorks首席科学家，也是《重构》一书作者Martin Fowler曾在演讲中指出，现今敏捷遇到的问题之一是，缺乏对技术专业重要性的重视。这些技术专业涉及了打造一个架构整洁、易于维护、品质优良的系统，或是关于如何建置一套高效稳定的开发部署流程，来缩短需求提出到上线的时间，来提升价值交付的速度，但要如何做到，敏捷无法告诉我们。

开发团队要抉择，做出“可以动就好的软件”还是一个“能够适应改变的软件”？业务单位要抉择，打造短期亮点的资讯系统“专案（Project）”，还是一个长期发展的资讯系统“产品（Product）”。

如果答案是后者，DDD、Agile及DevOps的融合，能够提供一个好的方向，打造出珍视合作互动及软件工艺、并能持续交付价值的敏捷团队。

 Q3：国外有哪些DDD知名案例？ 

 A  早在2015年推出奖励忠诚度计划的星巴克，在2016年时决定重新设计新版奖励平台时，就采用了DDD，打造出一个有能力处理十亿个事件的事件来源引擎。英国卫报十多年前的网站改版，就花了2年用DDD重新设计过一次。SalesForce 也曾以 DDD 来面对超过两万五千个开发者协同的复杂问题。

 Q4：台湾有哪些DDD实例？ 

 A  台湾已有一些早期先行者，试图在各行各业中实践。像是 KKDay在 2019年就试图引入DDD 与事件风暴工作坊 ，来加强业务团队与技术人员协作时的共同理解。大型企业如国泰世华银行、中国信托银行，都分别在 2020年开始投入更多实践，大家的目标都是在既有系统能因应快速创新的需求下，能将既有资产、系统更好地梳理业务流程，重整出高内聚、低耦合的一套有弹性的软件，希望未来有机会可以共用这些重新设计过后的系统。为此，越是大型复杂的应用场景中，DDD 几乎成了现代改造系统架构的首选。

 Q5：想了解DDD最新趋势，要追踪那些意见领袖？ 

 A  领域驱动设计之父Eric Evans、中国领域驱动设计传教士张逸、中国领域驱动设计社群组织者王威、创办Virtual DDD也是领域驱动设计顾问的Kenny Baas-Schwegler、《领域驱动设计样式、原理与实践》共同作者Nick Tune、Event Storming发明人Alberto Brandolini、以及《实现领域驱动设计》作者Vaughn Vernon。

 Q6：上手DDD的第一本书？ 

 A  实现领域驱动设计》(Implementing Domain-Driven Design, IDDD)和《领域驱动设计样式、原理与实践》 (Patterns, Principles, and Practices of Domain-Driven Design)。

另有一本《DDD 15年》，这是由23位领域驱动设计专家所共同著作。每一位作者各自撰写一篇文章，倾注了他们对于领域驱动设计的知识和实务的理解。由于每一位专家的背景和专注的专业领域不同，因此提供了运用领域驱动设计的丰富角度，例如像是从物件导向、函数式来运用DDD，内容非常全面。读完后可以感受到“原来领域驱动设计还能够这样运用！”。本书有多国翻译版本， DDD TW社群也着手翻译这本书，近期将以繁体中文发行。

 Q7：推荐那些DDD学习资源？ 

 A  有不少Youtube影音频道可以参考，如包括了Virtual DDD频道、Domain-Driven Design Europe频道、Vaughn Vernon频道、Explore DDD频道、KanDDDinsky频道、Domain-Driven Design Barcelona频道和Domain-Driven Design London，另外也推荐加入DDD TW 脸书粉专和Youtube频道。另外，DDD TW社群志工fx777，在2019年iT邦帮忙铁人赛中优选得奖作品“Think in Domain-Driven Design 系列”，以30篇文章详细介绍DDD和事件风暴的进行方式。

 Q8：企业IT要了解DDD，如何上手？ 

 A  可以加入DDD TW社群，社群提供了许多领域驱动设计的学习资源，可以避免企业在学习过程中的障碍。DDD TW社群会定期与中国和欧美各领域驱动社群或团体交流，来掌握领域驱动设计的理解及新资讯。

 Q9：业务团队要了解DDD，如何上手？ 

 A  可以先从工作坊，包括Event Storming或Domain StoryTelling着手，先感受领域驱动设计带来的好处。接着开始着手研读领域驱动设计战略部分的资讯，并且内化和整合到自己的业务知识，来理解到如何更好地将自身业务知识传递给团队，来降低沟通成本提高协作效率。

 Q10：台湾DDD社群目前规模？可提供什么帮助？ 

 A  这是一个由台湾软件现役从业人员所经营的非营利社群，在2021年1月已经达到2,624人。社群将借由多种不同类型的活动，将领域驱动设计的概念及实务和参与活动的朋友们分享与交流。DDDTW常规活动，有月例会、读书会和年会。

DDD台湾社群闪电崛起，接轨全球社群引进跨国开发实务

图片来源-DDD TW

在2018年底，一个下着大雨的夜晚。DDD TW社群发起人高翊凯和张国昭，在巷口小七超商的一段讨论后，花了2年，催生出一个核心志工团队16人，社群规模超过2,600人的软件开发社群。

高翊凯和张国昭好几年来，一直很想在台湾推广领域驱动设计，甚至在自身任职公司都尝试引入实践，但扩散效益仍旧缓慢。2017年张国昭还自费到北京参加首次DDD中国社群年会，亲身感受到海外社群的热情。2018年夏天，2人决定展开行动，先在脸书成立社群粉专，但是，半年下来仍只有百来人规模。

两人再次飞往中国参加第二届峰会，结识了中国社群关键组织者王威和张逸，他们都是在中国软件领域的实践家和意见领袖，也成了台湾社群发展跨区域协作的契机。所以，高翊凯和张国昭在下雨那夜订出5大发展愿景，扩大社群触及人数、组织线下读书会、透过MeetUp挖掘台湾专家来交流、接触全球DDD领域最大社群DDD Europe建立连结、培养社群新血和核心志工。

有了更明确的目标，2019年DDD台湾社群开始快速发展，那一年就办了超过20场的线下读书会和Meetup活动，社群规模首度超过了1千人，透过读书会也逐渐组成了核心志工团队。还在年底举办了一个连续数周的微服务黑客松开发竞赛，也获得厂商赞助。

中国DDD社群看到了台湾DDD社群快速崛起，在2019年底的峰会直接邀请高翊凯和张国昭登台分享，张国昭的演讲还获选为最受欢迎的主题。不只在中国，高翊凯也积极将台湾社群经验发布到DDD Europe社群中，因此而结识了欧洲社群的主要组织者，打开了与全球社群协作的管道。

2020年疫情让远距协作成为主流，DDD Europe因此成立了一个全球性虚拟DDD社群，更在2020年5月，举办了一场24小时马拉松的全球线上大会，台湾DDD社群是欧美以外，唯一一个受邀的在地社群。高翊凯和张国昭被安排在第一组讲者，后面紧接着登场讲者是DDD之父Eric Evans、《实现领域驱动设计》作者Vaughn Vernon和Event Storming发明人Alberto Brandolini等当代一线软件顾问大师。从此，台湾的DDD TW社群正式与DDD Europe社群搭上线，多位欧洲DDD专家更在2020年底远距参与台湾年会，分享最新DDD经验。

2020年11月底，举办了一连两天的首届台湾领域驱动设计年会，涵盖了产品、流程、设计三大议题，讲者除了来自中国、英国、荷兰等地社群之外，也有台湾老、中、青三代的讲者。参加者超过330人，3成来自金融业，多家金控也派员参加。除了企业高阶主管、IT与研发、也有来自业务、行销端的从业人员。第二天活动一口气举办了6场工作坊，超过120人参加，最抢手的就是事件风暴工作坊，还得额外加课。

DDD TW社群每个月会找来业界有领域驱动设计实务经验的第一线专家分享实践经验，不只技术，还包含团队协作与业务分析。对于领域驱动设计经典书籍的读书会持续进行，未来计划细分为初阶与进阶两个等级。透过DDD Europe社群联系，台湾DDD TW社群也正将2019年在欧洲大卖的新书《DDD 15 Years》（中译《DDD 十五周年》），透过社群志工力量，翻译成繁体中文版，预定2021年上半年发行。