首页 > 科技 > 计算机 > 计算机科学

创新驱动设计：单体与微服务混合架构策略与实践

作译者：娄麒麟等

出版时间：2024-03 千字数：352 版次：01-01 页数：288

开本：16开装帧： I S B N ：9787121473517

换版：

纸质书定价：￥115.0

库存:无

分享到：

共有图书评论0条【查看评论摘要】

看了又看

{{data.bookName}}

￥{{data.price}}

内容简介

前言

上架建议

作者简介

编辑推荐

音视频专区

第1部分  通过实验学习转型战略
第1章  业务目标和数字化转型	5
数字化转型的目标是什么	6
软件架构概览	8
为什么软件项目会出问题	9
债务隐喻	10
软件熵	11
大泥球	11
案例研究	13
当前的业务背景	14
商机	15
企业与康威定律	16
知识传递	17
知识不是实物	17
电话游戏	18
艰难的一致	19
但是一切皆有可能	20
（重新）思考软件战略	22
思考	22
反思	24
单体系统一定不好吗	27
微服务一定好吗	28
善待敏捷	30
摆脱困境	33
小结	34
第2章  基本战略学习工具	35
决策的早晚和对错	36
文化和团队	39
失败而不是死亡	40
失败文化不是指责文化	41
康威定律的正确用法	43
启用安全实验	46
模块化优先	47
部署放最后	50
介于两者之间的一切	52
业务能力、业务流程和战略目标	52
针对性的战略交付	56
利用Cynefin进行决策	60
你的意大利面条在哪里，煮得有多快	63
战略架构	64
应用工具	65
小结	67
第3章  事件优先的实验和发现	68
命令与事件	69
使用软件模型	71
利用事件风暴快速学习	72
当需要远程事件风暴会议时	74
主持会议	75
宏观建模	79

应用工具	82
小结	88
第2部分  推动业务创新
第4章  获得领域驱动的成果	94
领域和子域	96
小结	99
第5章  专业知识上下文	101
限界上下文和统一语言	101
核心子域	105
支撑子域、通用子域和技术机制	106
支撑子域	107
通用子域	107
技术机制	108
业务能力和上下文	108
别太大，也别太小	110
小结	112
第6章  映射的两面：成功还是失败	113
上下文映射图	113
合作关系	115
共享内核	117
客户方-供应方开发	118
遵奉者	120
防腐层	122
开放主机服务	123
发布语言	128
另谋他路	130
地形建模	130
失败之道与成功之径	133
应用工具	136
小结	141
第7章  建模领域概念	142
实体	143
值对象	144
聚合	145
领域服务	146
函数式行为	147
应用工具	149
小结	150
第3部分  事件优先架构
第8章  基础架构	155
架构风格、模式和决策	157
端口-适配器架构	157
模块化	163
REST请求-响应	166
质量属性	168
安全性	168
隐私性	171
性能	173
可伸缩性	175
弹性：可靠性和容错性	175
复杂性	177
应用工具	177
小结	178

第9章  消息驱动和事件驱动架构	179
基于消息和事件的REST	183
事件日志	183
订阅者轮询	185
服务器发送事件	186
事件驱动和流程管理	187
事件溯源	189
CQRS	193
无服务器架构和功能即服务	195
应用工具	197
小结	197
第4部分  两条通向目标架构之路
第10章  构造单体	203
历史回顾	205
慎终于始	207
业务能力	208
架构决策	210
是与非	215
随变化而变化	217
解耦	220
坚持正确的步伐	224
小结	225
第11章  从单体到微服务	227
做好心理建设	227
从模块化单体到微服务	230
从大泥球单体到微服务	234
用户交互	235
协调数据变化	237
决定绞杀什么	242
拔掉遗留单体	244
小结	245
第12章  平衡要求，管控需求	246
质量属性平衡	246
战略和目标	247
业务目标呼唤数字化转型	247
使用战略学习工具	248
事件驱动的轻量级建模	249
推动业务创新	249
事件优先架构	250
单体架构作为首要关注点	250
有针对性地将单体拆分为微服务	251
平衡是不偏不倚的，创新是必不可少的	252
小结	252

推荐序1
六年前，我作为一名领域驱动设计（DDD）的实践者，怀着极大的兴趣，在短短一天内翻阅完Vernon的《领域驱动设计精粹》。那时，我深刻体会到团队在实践DDD时遇到的迷茫，同时也被Vernon引领开发团队的实际操作所鼓舞。
收到本书的翻译校审稿后，我意识到两位作者不是仅将DDD的概念停留在理论层面，而是深入组织层面的应用，从用户角度出发，探讨了企业如何利用软件确保数字化实际成效，以及如何超越微服务架构或云原生技术细节带来的局限。
“软件正在吞噬世界”，这句话预示着数字化时代的来临，而企业数字化转型的关键在于如何利用软件进行创新。本书从软件的特性出发，阐述了如何将软件开发和应用转化为盈利中心，并基于此实现战略创新。SpaceX等科技创新公司已经向我们证明了这种创新的巨大价值。作者通过将DDD理念应用于构建企业的创新基础，提供了诸多值得数字化转型决策者深思的见解。
组织在创新时需要具备实验和学习的能力，而许多企业习惯高度确定性的专业分工，二者明显相悖。承包模式不利于组织级学习和实验性尝试，专业团队往往只能机械地执行任务。相对而言，“工程模式”倡导面向企业整体目标的工作方式，鼓励跨专业团队创造价值，而非仅仅完成某一项专业任务。从软件的敏捷开发到SpaceX在航天领域的创新，都体现了工作模式的这一转变。
作者强调：“单体架构不一定是坏事，微服务架构也不一定适合所有情况，根据业务目标选择架构才是最负责任的行为。”这一观点体现了数字化转型企业所追求的业务与技术的融合。今天，我们必须认识到，在智能化时代，不仅功能开发需要迭代，架构设计同样需要不断进化。正如DDD致力解决的核心问题——统一语言，只有不断地将业务目标与软件架构保持一致，才能确保软件架构沿着正确的方向发展。这种业务与技术融合的必要性，在金融等数字化先行行业已得到充分证实。
在这个变化无常、充满不确定性的科技创新时代，我们需要借鉴作者从事物本质出发的思考方式，以科学的认知来应对变革。积极主动地寻求变革，才能为组织深植创新的基因。
肖然
Thoughtworks中国区总经理
中关村智联联盟秘书长

推荐序2
当我作为一名独立顾问，在帮助企业开展数字化转型时，常常面临以下挑战：
?数字化转型缺乏战略规划的指导，企业的IT生态没有得到全面梳理，建设者多数以一叶障目的方式盲目推动数字技术升级和IT架构优化。
?数字化转型的过程充满不确定性和复杂性，建设者却期待以更加不确定的数字化建设路线、更加复杂的架构思维去解决问题。最后，因为得不到明显的投资回报，数字化转型工作“出师未捷身先死”。
?业务和技术在架构蓝图与团队组织两个方面“各自为政”，没有形成正确的映射关系，更谈不上完美地融合。业务创新无法引导技术创新，技术创新也驱动不了业务创新。
?各个核心系统贸然开始从单体向微服务的转型，并力图推动IT系统的全面云原生化，然而，因为缺乏对战略架构的通盘考虑，最终只是打造出一种新形式的微服务烟囱。
要应对这些挑战，坦白说，作为顾问的我们，手中握有的制胜筹码并不多。我们很难改变客户急功近利的心态，很难打破企业的部门墙，很难用简单的方案破解复杂的问题，很难用显而易见的成功持续推动商业模式的创新，自然也很难用纯粹技术的力量改变企业内部人员看到的“全世界”。
直到读到Vernon的这本新作，我惊喜地发现，它为我增加了不少制胜的筹码。书中的一些观点与方法构筑了杠杆的支点，可以帮助我们以更小的力量撬开拦在转型道路前的巨石。例如书中的第1部分，它的标题“通过实验学习转型战略”就给了我很大的启发。数字化转型的战略规划当然不能一蹴而就，也不能毫无计划就赤手空拳踏上转型之路。通过实验学习转型战略，就能在一定程度上规避风险，让转型工作能够在持续反馈的过程中得到印证和调整。学会运用书中介绍的“基本战略学习工具”，在一定程度上可以战胜前面所述的第一个和第二个挑战，书中第3章介绍的“事件优先的实验和发现”正好是第三个挑战的一种应对思路，这一思路的技术层面在本书的第3部分“事件优先架构”得到进一步完善。虽然在转型过程中，IT的架构决策未必一定采用事件优先架构，但它完全可以作为一种利器放到云原生化的工具箱中，随时待用。
本书的第4部分探讨和比较了单体与微服务，这一主题构成了本书中文版副标题的内容，即“单体与微服务混合架构”。我在2020年DDD中国峰会上，也曾向各位听众叩问过——“单体架构是邪恶的吗？”——这一问题。我的结论是：将单体架构与微服务架构作为对比并不正确，单体也不一定会走向大泥球。关键在于限界上下文，它可以作为应用架构的基本架构单元，并根据质量属性来决定架构单元的粒度和边界，从而成为平衡单体和微服务的重要砝码。这一结论与本书第4部分的观点不谋而合。单体与微服务混合架构完全可以响应变化，做到进退自如，单体与微服务之争可以休矣！
说起来，我与本书作者Vernon颇有渊源。2013年，我的同事滕云隆重向我推荐了Vernon的Implementing Domain-Driven Design（中文版书名为《实现领域驱动设计》）。在第一次知道Vernon的大名并拜读到他的大作后，我更加深刻地理解了DDD，许多困惑迎刃而解。之后，我作为该书审校得以进一步深度阅读滕云翻译的中文版。2014年，ThoughtWorks甚至邀请Vernon在北京开展了为期两天的IDDD工作坊，我有幸当面向Vernon请教。以其人为榜样，以其书为参考，我历时多年完成第二本个人专著《解构领域驱动设计》。这几年，我融合领域驱动设计、企业架构、云原生架构与DevOps敏捷管理方法总结出一套应用现代化方法体系，以帮助企业全面实现数字化转型。恰逢其时，这次又读到Vernon这本与数字化转型有关的新作。如同十年前为我解惑，他最新的软件战略与架构思想又一次成为“及时雨”，帮助我更好地应对数字化转型的诸多挑战！
张逸
数字现代化独立顾问
《解构领域驱动设计》作者

推荐序3
不可否认，微服务（Microservice）架构模式有诸多好处。
它将应用程序拆分为小的、独立的服务，每个服务都专注于 实现特定的业务能力。由于每个微服务都可以独立部署，团队可以更频繁地发布更新，更快地响应用户的需求或反馈；每个微服务都由一个相对较小的团队负责开发和维护，而团队自治的模式可以提高团队的生产力和创造力，也更便于团队根据特定服务的需求来选择最适合的技术栈。
虽然有诸多好处，但是这些好处不是凭空获得的，需要有诸多投入作为代价。比如，需要团队具备快速获取环境（Rapid Provisioning）的能力、快速部署服务的能力、对服务环境的观测能力，以及按照运行情况做出快速响应的能力等。
这些能力往往都不“便宜”。比如，我最近听到一个观测能力有关的例子：在一个由100多个微服务构成的系统中，业务数据只有10T，而每日产生的观测数据大约是34T。
鉴于上述分析，如何在获得微服务的诸多好处的前提下，控制这种架构风格带来的成本膨胀，并且获得可持续的投资回报率，业已成为在深水区践行微服务的必修课。本书提供了绝佳的总结与思考，值得每一个微服务实践者仔细阅读。
徐昊（八叉）
ThoughtWorks全球技术战略委员会成员

译者序
本书出现在一个特殊的时代——人工智能（AI）是否会取代软件工程师的问题引发了热烈的讨论。我和我的同事们也不可避免地参与了这场讨论。虽然我确信，在未来的某个时刻，人工智能必将取代人类软件工程师，然而这个时间点仍然未知。在2022年年底，OpenAI发布了ChatGPT，我一度以为这个时刻已经来临。如同TDD的发明者Kent Beck所说：“（有了ChatGPT以后，）我90%的技能都变得毫无价值，同时剩下的10%的技能则增值了1000倍。”但随着我对ChatGPT（包括GPT4）的深入使用，我逐渐意识到当前AI的局限性，比如丢失上下文和缺乏最新知识等，这也意味着我还能在“传统软件工程师”行业再待一段时间。因此，对于我们人类程序员来说，本书仍具有翻译的价值，除非AI技术一夜之间进化到“面向意图编程”。
既然我们人类程序员仍需要发光发热，那么开发软件项目时面临的诸多问题也将凸显出来，比如跨团队协作的困难、知识魔咒，以及程序员们对最新技术的狂热追求。当然，从组织层面来看，部分人可能还会产生其他问题，比如对现状的满足，或者过于喜欢指责他人。这些问题都可能阻碍软件项目的进展。幸运的是，沃恩和托马什在本书中为我们一一解答了这些问题，使得我们能够把软件开发重新引向业务价值的道路。是的，在我看来，本书正是这样一本让软件项目得以成功甚至卓越的武功心法，它并没有介绍具体的一招一式，但是能帮助读者避开各种陷阱，这当然源于作者数十年咨询工作的经验，所谓身经百战、厚积薄发。
我在过去的十来年里参与过各种项目，有的项目落入了“维护模式”的陷阱，有的为了追求时髦而选择了全面微服务化。我也见过一些按照知识领域划分的团队，他们采用了ADR、事件驱动，以及本书中提到的其他工具和技术。正因为有这些经历，我在阅读本书时产生了深深的共鸣。因此，当博文视点的编辑问我是否愿意翻译本书时，我毫不犹豫地接受了这个任务。然而，我只是对云原生和函数式编程较为熟悉，但对DDD的了解相对浅薄，我深恐不能完成翻译任务。在翻译和校对的过程中，我的同事马建勋和姚琪琳参与了进来，他们以丰富的经验完善了本书近一半的翻译表述。感谢ThoughtWorks DDD社区的同事张渝，他在前期承担了两章内容的翻译工作。同时，也要感谢远在澳洲的孟然，他为本书的翻译提供了宝贵的建议。我原本以为我们能在两三个月内完成本书的全部翻译，但现实证明我过于乐观了。项目的交付压力、家庭事务，以及突如其来的疫情，都对翻译工作产生了或多或少的影响。
由于译者才疏学浅，并不一定能够完全展现作者对软件开发和咨询领域的深刻见解。如果存在错漏，实属不该，请联系我们予以修正。
最后的最后，感谢和我一起翻译本书的马建勋、姚琪琳、张渝，感谢编辑们对翻译工作的支持，感谢我的家人对我工作的理解。希望本书能帮助那些正在追求卓越软件开发的人们，也希望你享受阅读本书的过程。
娄麒麟
2023年8月，于西安

序
在2007年4月，我们遇见了Iterate公司的创始人。他们中的三位参加了我们在奥斯陆举办的首次研讨会，并邀请我们共享晚餐。在晚餐期间，我们得知他们刚刚离开了一直从事的咨询工作，创建了自己的公司，希望将值得信任的技术应用到热爱的领域。我心里想：“祝你们好运吧。”毕竟他们刚刚毕业几年，尚无管理企业的经验。然而，在我们讨论如何寻找良好的客户和协商敏捷相关合作的合同时，我并没有表露出自己的疑虑。
在接下来的十年里，我们多次拜访Iterate，见证了它成长为一家成功的咨询公司，并经常被列为挪威最佳工作场所之一。这家公司现在拥有众多顾问，业务涵盖从软件开发到测试驱动开发，再到帮助公司通过设计冲刺进行创新等多个领域。因此，当几位创始人在2016年决定转型时，我虽然觉得这是预料之中的，但仍然感到惊讶。
当时，他们告诉我：我们决定改变方向，希望打造一个让员工充分发挥潜力的伟大工作场所，但我们发现，作为顾问的优秀人才在职业发展上受到了很大的限制，因为他们一直在追求别人的梦想。我们希望创造一个平台，在这里，人们可以释放自己的热情，并有机会创立自己的公司。我们想要孵化创业公司，并利用我们的咨询业务收入来资助这些公司。
我又一次在心里嘀咕：“祝你们好运吧。”而这次我并没有将疑虑藏在心中。我们讨论了创业公司的高失败率及我在3M公司时的座右铭：“尝试多样的，保留有效的。”这对拥有充足时间和资金的人来说是一个很好的座右铭，但他们两者都没有。其中一位创始人对这个新方向并不认同，选择了离开。而其他人则继续他们一直以来的方式——逐步向前推进，对目标进行迭代。
这并不容易，也没有现成的模板可以参考。他们想避免外部资金的影响，因此决定将咨询和风险投资这两种截然不同的业务模式融合在一起，他们将咨询利润的3%留给咨询业务，将剩余的资金全部用于风险投资。他们必须确保咨询顾问不会感到被边缘化，同时要求从事风投的人也对咨询业务的成功有所贡献。此外，他们还需要学习如何帮助创业公司成功，因为他们过去只做过咨询业务。
自2016年起已过去五年。每年我们都会参加他们的头脑风暴会议，帮助Iterate实现其独特方法。然而，当疫情暴发时，他们的咨询业务不仅停滞不前，同时耕耘了三年的“农场到餐厅”业务也未能找到餐厅买家。但想一想：现在Iterate这里有一批高水平但无事可做的人才，以及一家专门收集和运输易腐货物的初创公司。他们仅用了两周就实现了转型——为消费者提供路边自提食物服务，打通了配送的“最后一公里”。这项服务迅速获得了成功。在2020年，尽管奥斯陆的大多数咨询公司都受到严重打击，但是Iterate凭借对“最后一公里”配送机会的洞察脱颖而出，并成功孵化出另外三家公司，其中一家做船舶定位系统，还有一家是面向编织者、毛线供应商和消费者的三方平台。意外的收获是，Iterate被Fast Company评为2020年最佳创新工作场所第50名，超过了Slack、Square和Shopify。
那么，Iterate是如何克服众多困难获得成功的呢？创始人从一开始就认识到，将软件开发视为咨询项目的方式无法为他们提供足够的自主权。随着软件逐渐成为战略创新的杠杆，他们认为是时候在决策层面占有一席之地了。这个想法在当时确实令人畏惧，因为这意味着要对结果负责，这是咨询顾问通常会避免的。然而，他们有信心，他们的试验性方法不仅可以解决技术难题，也能应对商业难题，因此他们果断地迈向了未来。
你可能会认为，Iterate的转型与本书所讨论的企业转型没有太大关系。Iterate的故事中并未提到单体架构、微服务或敏捷实践——但转型的本质并不在于此。正如本书指出的，转型始于对新的创新业务战略的阐述，这种战略向市场提供真正的、有差异化的价值。追求这一战略将是一段漫长且充满挑战的旅程，它需要优秀的人才、深入的思考及大量的学习。对于正在进行此类转型的人来说，本书为你的旅程提供了许多思考工具。
打个比方，当你朝着新的方向前进时，你可能不愿意摧毁那些虽然过时但仍为你带来收益的架构。你需要那个旧的大泥球单体（或咨询服务）来资助你的转型。
再举一个例子：你首先需要考虑的是适合新业务模型的架构，它可能与旧模型有所不同。就像Iterate从拥有一群顾问转变为拥有明确职责划分的创业团队一样，你可能也希望为你所在的领域构建新的架构。这通常意味着需要明确适应新战略的业务能力，并围绕这些能力构建完整的团队。因此，你可能不会倾向于采用分层架构，而是希望基于产品的自然组件和子组件（也称为限界上下文）来构建架构。
以SpaceX为例，火箭的架构是由其组成部分决定的：第一级火箭（包含9台Merlin发动机、1个长整流罩和一些着陆架）、中间级、第二级火箭和载荷。团队的组建并不是根据工程学科（如材料工程、结构工程、软件工程）进行的，而是根据组件和子组件进行的。这为每个团队都提供了明确的责任和一系列限制条件：团队需要理解并完成其组件要求完成的工作，以确保下一次发射成功。
随着在新战略中明确产品架构，你可能会想创建一个与该架构相匹配的组织，因为正如本书作者所指出的，你不能违反康威定律，就像不能违反万有引力一样。本书的核心是一系列思维工具，这些工具可以帮助你设计一个新的架构（很可能是一个模块化的单体），以及建立支持该架构所需的组织。本书还提供了逐步从现有架构向新架构迁移的方法，并给出了何时及如何剥离某些服务的建议。
随着时间的推移，Iterate公司发现成功的创业公司有3个元素：
?良好的市场时机。
?团队凝聚力。
?技术卓越。
判断市场时机需要耐心。那些认为转型只与新流程或数据结构有关的组织往往缺乏耐心，因此在这一点上常常做出错误的判断。转型的真正意义在于营造一个环境，让创新得以繁荣，以创造新的、有差异化的产品，并将产品在正确的时机推向市场。
成功的第2个元素是团队凝聚力，它源于允许正在开发的能力（限界上下文）和相关的团队构成随着时间的推移而不断演化，直到找到最适合的人员组合和产品。
成功的第3个元素是技术卓越，它根植于对软件技术复杂性的深刻尊重。本书将帮助你认识到现有系统和未来版本的复杂性，以及从一个版本演进到另一个版本所面临的挑战。
Iterate的故事提醒我们：转型并不容易。Iterate必须巧妙地将咨询团队与风险团队整合在一起，以便让每个人都感受到自己的价值，并致力于组织的整体成功。这是每个组织在经历变革时都会遇到的问题。成功的路径除了要具备本书提到的高技能人才、深入的思考和持续的实验，别无他途。
没有银弹。
——Mary Poppendieck，
《精益软件开发》的共同作者

前言
很可能你的组织的赚钱方式与传统意义上的软件销售无关，未来也可能不会与软件直接相关。但这并不意味着软件不能在你的组织的营利中发挥重要作用。事实上，软件正是那些最具价值的公司的核心。
以FAANG（指Facebook、Apple、Amazon、Netflix和Google，Facebook现更名为Meta，Google现更名为Alphabet）为例。这些公司几乎都不直接出售软件，或者说软件销售不是它们的主要收入来源。
Facebook大约98%的收入来自向希望接触其社交网络用户的公司销售广告位。这些广告位之所以如此有价值，是因为Facebook的平台极大地增强了用户之间的互动。用户关心其他用户和整体趋势，这使得他们持续关注人群、事件和社交平台。获取Facebook用户的关注对广告商来说价值巨大。
Apple主要是一家硬件公司，销售智能手机、平板、可穿戴设备和计算机。软件使这些设备的价值得以最大化。
Amazon通过多种途径产生收入，既作为在线零售商销售商品，也销售电子书、播客、音乐和其他订阅服务，还销售云计算基础设施。
Netflix提供电影和其他视频流媒体服务，通过销售不同等级的订阅服务来获得收入。该公司还通过DVD订阅服务赚钱，但随着视频点播的日益流行，这部分业务的下滑在预期之中。面向用户的软件运行在电视和移动设备上，视频流媒体是通过其进行增强和控制的。然而，真正的复杂性来自部署在亚马逊云上的系统，这些云系统提供了超过50种不同编码格式的视频，通过内容分发网络（CDN）提供内容，并在遇到故障时处理故障。
Google的收入也主要依赖于销售广告，这些广告展示在其搜索引擎的查询结果中。2020年，Google通过直接提供软件应用（例如 Google Workspace）获得了约40亿美元的收入。但与传统的软件不同，Google Workspace不需要被安装在用户的计算机上，而是以软件即服务（SaaS）的模式在云上运行。根据最新的报告，Google占据了近60%的在线办公套件市场份额，超过了微软。
从这些行业领导者的经验可以看到，组织并不需要销售软件就能获得领先市场的收入。然而，为了在当前和未来的业务中表现优秀，组织确实需要利用软件。
此外，组织要通过软件推动创新，就必须认识到一群优秀的软件架构师和工程师的重要性。这些顶尖的人才因其重要性而变得难以招聘。可以将这个情况比作WNBA或NFL的选秀：前20名选手对球队来说至关重要。当然，这并不适用于所有的软件开发者。有些人满足于“打卡上班”，支付他们的房贷，并尽可能多地挤出时间看 WNBA和NFL的电视节目。如果这些人是你所希望招聘的，我们强烈建议你立即停止阅读本书。然而，如果你希望做出有意义的改变，那么请继续阅读。
对于那些追求卓越和加速创新步伐的组织来说，仅仅理解优秀的软件开发人员的价值是不够的。如果一家企业想要通过软件创新来主导所在行业，那么它必须认识到这些软件架构师和工程师是“新的决策者”（The New Kingmaker）——这个概念由Stephen O’Grady在他2013年出版的著作The New Kingmakers: How Developers Conquered the World（见参考文献0-3）中提出。为了真正成功地开发软件，所有有雄心壮志的企业都必须理解是什么驱使这些开发人员超越了常规的软件开发方式。他们渴望创造的软件远非平凡之作。最有价值的软件开发人员希望创造能够决定行业未来的软件，这正是你的组织在招聘过程中应该传达的信息，以便吸引最优秀的人才和有足够动力做到最好的人才。
本书适合C级管理者和其他高管，以及所有职位和级别与软件开发相关的人员。如果软件交付能直接导致战略差异或支持战略差异，那么其负责人都应该了解如何通过软件推动创新。
作者发现，今天的C级管理者（如CEO）和其他高管与他们几十年前的前辈有所不同。他们中的许多人非常熟悉技术，甚至可能被视为业务领域的专家。他们对改善特定领域有深远的洞见，并成功吸引了其他高管和理解创始人目标的技术专家。以下人员可能会发现本书特别有用。
?那些紧跟技术愿景的CEO，比如创业公司的CEO，以及希望洞悉软件在未来企业中的作用的CEO。
?那些致力于推进和实现软件开发差异化的CIO。
?那些通过创新引领软件愿景的CTO。
?高级副总裁、副总裁、总监、项目经理等，他们负责实现愿景。
?可从本书中获得启示的首席架构师。本书也是激励软件架构师和高级开发人员团队以商业思维和有针对性的架构推动变革的重要指南。
?所有级别的软件架构师和开发人员。他们需要发自内心地树立商业思维，意识到软件开发不仅仅是赚取高薪的手段，更是通过软件创新实现卓越成就的途径。
本书包含了所有软件专业人士必须掌握的重要信息，通过消化、吸纳和实践本书探讨的专业技术，可以实现持续创新。
本书并非一本专注于具体实现细节的书。我们将在接下来的图书Implementing Strategic Monoliths and Microservices中提供更多实现细节。本书主要聚焦于软件如何作为业务战略的一部分。
对于缺乏软件行业深度知识或经验的领导者来说，本书是极具吸引力的。它通过阐述每个软件举措应有的愿景、有针对性的架构设计、战略的设计和实现来实现有效的信息传达。同时，我们强烈建议读者避免有意或无意地将复杂性引入软件。推动变革的关键在于提供超出用户或客户期待的软件。因此，本书旨在挑战那些坚守现状、保护自己工作岗位的人，鼓励他们接受新一代的思想、方法和工具，以期成为未来产业的创新者。
本书的作者曾与许多不同的客户合作，亲眼见证了软件开发中的负面现象。比如，有人把保住工作和捍卫自己的地盘视为主要目标，而非推动企业的创新发展。许多大型企业如此庞大，存在复杂的管理和汇报架构。这些企业同时推动多项举措，但“愿景—实现—接受”的路径并非顺畅无阻。基于此，我们试图唤醒人们，让他们认识到“软件正在吞噬世界”的真实性。本书的内容带有现实主义色彩，表明创新可以通过逐步进行的实践来实现，而不必寄希望于瞬间的巨大飞跃。
尝试创新总是伴随着风险。然而，从长远来看，完全不冒任何风险可能更加危险。下面的图P.1清楚地说明了这一点。
正如Natalie Fratto指出的（见参考文献0-1），通常情况下，冒险的风险随着时间的推移而减少，但什么都不做的风险却会随着时间的推移而增加。在她的TED演讲中（见参考文献0-2），我们可以看到Natalie作为一名风险投资人的观点，她解释了所投资企业创始人的类型。她说，许多投资者寻找具有高智商（IQ）的创始人，而另一些投资者则寻找具有高情商（EQ）的企业家，而她主要寻找那些具有高适应性指数（AQ）的人。实际上，创新需要极高的适应性，这个观点在本书中以多种形式被反复强调。从实验到发现，再到架构、设计和实现，都需要适应性。除非具有高度的适应性，否则冒险者很难成功。
在讨论软件创新的主题时，我们不可避免地会涉及迭代和增量开发，这是一个具有高度争议的主题。事实上，某种形式的敏捷论调是无法回避的。本书避免了宣传特定的敏捷或精益方法。遗憾的是，大多数声称采用敏捷思想的软件公司和团队，并不真正理解如何做到敏捷。我们的愿望是强调理解而非采用。敏捷的原始理念非常简单：它专注于协作交付。如果保持简单，敏捷可以非常有用。然而，这并不是本书的主要关注点。我们只想指出，采用“复杂”的敏捷可能会带来的损害，以及敏捷方法如何提供帮助。关于我们如何看待敏捷方法能提供的帮助的简短讨论，请参见第1章中的“善待敏捷”部分。
考虑到我们的背景，一些读者可能会惊讶地发现，我们并不将本书视为一本关于领域驱动设计（DDD）的书。当然，我们确实介绍了领域驱动设计的方法和优点，以及如何使用它，但我们并没有将自己局限于DDD，而是提供了更广泛的观点。本书旨在应对这样一个现实需求：“软件正在吞噬世界，因此我们需要聪明地与时俱进，进行创新，做出基于实际目标的明智架构决策，否则我们就会落后。”我们解决的是多年与各种公司打交道遇到的实际问题，特别是我们过去五到十年观察到的问题。
我们有点担心，用来提醒大家的鼓点听起来可能会太响。然而，对比其他由科技驱动的行业周围的鼓点，我们认为自己的声音是必要的。当其他人在高山上不断敲打着“下一个被高估的产品就是银弹”的鼓点时，我们觉得至少需要一些对应的声音，用来提醒人们，大脑才是最好的工具。我们的目标是展示出真正的创新来自思考和反思，而不是购买通用产品或者不断投入技术力量来解决难题。所以，请把我们看作在相邻的另一座山上敲打着“成为科学家和工程师”的鼓点的人，我们希望你能通过创新和独特的方式超越平凡。确实，我们在这个过程中付出了很多汗水。如果我们强烈的鼓点声给读者留下了一些深刻的印象，那么我们认为自己已经实现了目标。如果这种刺激能够引导我们的读者获得更大的成功，那就再好不过了。
图P.2展示了本书大多数架构图中使用的建模元素。这些元素的规模从大到小不等，取决于图表的主题。其中一些元素来自事件风暴部分。
在图P.2中，上半部分是战略和架构元素：业务/限界上下文是业务能力和知识领域的软件子系统及模型边界；大泥球是许多企业所处的“无架构”状态；端口和适配器表示既有基础功能又富有灵活性的架构风格；模块是包含软件组件的有独特名字的包。
图P.2的下半部分描绘了8种战术组件类型：命令引起状态转换；事件捕获和记录跨子系统边界的状态转换；策略描述业务规则；聚合/实体保存状态并提供软件行为；用户角色与系统进行交互，通常代表一个角色；视图/查询收集和检索可在用户界面上呈现的数据；进程管理多步操作，直至操作全部完成；领域服务提供跨领域的软件行为。它们存在于子系统内部，有时会流向其他子系统。

查看更多 > 图书评论

暂无评论

发表图书评论

评论标题：
评论内容：
验证码：: 看不清楚
点击刷新
: 您还没有登录，请登录后再评论。
点击“登录”

购买过本书的顾客还买过

{{data.bookName}}

￥{{data.price}}