《中台架构与实现》读书笔记

《中台架构与实现》读书笔记

1. 基于微服务架构来构建企业级应用已成为业界趋势。微服务架构很好地实现了应用解耦’可以更好池实现应用上云’解决单体应用扩展和弹性伸缩能力不足的问题。

2. 作为中台，需要将通用的业务能力沉淀到中台业务模型，实现企业级业务能力复用。

3. DDD首先从业务领域人手’划分业务领域边界，采用事件风暴工作坊方法’分析并提取业务场景中的实体、值对象、聚合根、聚合、领域事件等领域对象’根据限界上下文边界构建领域模型，将领域模型作为微服务设计的输人’进而完成微服务洋细设计。用DDD方法设计出来的微服务，业务和应用边界非常清晰，符合“高内聚’低耀合”的设计原则，可以轻松适应模型变和微服务架构演进。

4. 目录

   • 本书主要包含24章，共分为6部分。
     第一部分认识中台（第1～4章）
     本部分包括4章’主要介绍中台相关背景知识，认识并理解中台的真正含义，从业务中台、数据中台、技术中台以及与之匹配的组织架构等多个方面分析传统企业中台转型应该具备的能力，带你初步了解DDD是如何指导中台和微服务设计，并厘清它们的协作关系的。
     第二部分DDD基本原理（第5～11章）
     为了让你能够更加深刻地理解DDD’本部分通过＿些浅显易懂的案例’帮助你学习并深刻理解DDD的核心基础知识、设计思想｀原则和方法等内容’了解它们之间的协作和依赖关系，解决DDD概念理解闲难的可题’做好中台实践前的准备工作。本部分包括7章’主要讲解DDD的关键核心知识体系，包括领域｀子域、核心子域、通用子域、支撑子域、限界上下文｀实体｀值对象、聚合｀聚合根、领域事件和DDD分层架构等知识。
     第三部分中台领域建模与微服务设计（第12～19章）
     本部分包括8章，主要介绍DDD是如何通过战略设计构建中台业务模型’以及如何通过战术设计指导微服务拆分和设计的。在这＿部分’我会用多个实际案例，带你用DDD方法完成中台和微服务的全流程设计’深刻理解DDD在中台领域建模与微服务设计中的步骤、方法｀设计思想和价值。
     l ）了解如何用事件风暴方法构建领域模型。
     2）了解如何用DDD设计思想构建企业级可复用的中台业务模型。
     3）了解如何用DDD设计微服务代码模型，如何将领域模型映射到微服务以建立领域模型与微服务代码模型的映射关系’如何完成微服务架构演进等。最后用—个案例将DDD所有知识点串联在一起，带你深人了解如何用DDD的设计方法完成领域建模与微服务设计的全流程’并对代码示例进行了详细分析和讲解。
     第四部分前端设计（第20章和第21章）
     本部分包括两章’主要介绍微前端的设计思想，通过前端微服务化和单元化的设计思想’解决业务中台建设完成后前端应用解锅和前后端服务集成复杂的难点。书中阐述了如何借鉴 微服务的设计思想来解构前端应用’实现前端应用的拆分解锅’并结合实践介绍前端架构的转型策略与技术落地。另外’本部分还探讨了基于领域模型的单元化设计方法。通过微服务与微前端组合后的单元化设计’既可以降低企业级前台应用集成的复杂度，又可以让企业具有更强的产品快速
     发布和业务响应能力.这种能力能给我们的团队组建、研发模式｀业务能力发布等带来非常
     大的价值。
     第五部分中台设计案例（第22章）
     本部分包括—章，通过保险订单化设计案例’采用自顶向下的领域建模策略’带你走—遍中台设计的完整流程。案例中涵盖业务领域分解、中台领域建模｀微服务和微前端设计｀单元化设计以及如何实现业务和数据融合等内容’希望能够帮助你加深对DDD｀中台、微服务和微前端等知识体系、设计思想和技术体系的全面理解，更好地投人DDD｀中台利微服务建设实践中。
     第六部分总结（第23章和第24章）
     本部分是全书的总结，包括两章。书中结合我多年的设计经验和思考’带你了解单体应用向微服务架构的演进策略’如何避免陷人DDD设计的常见误区’微服务设计原则以及分布式架构下的关键设计等内容。

5. 背景：企业尤其是巨型企业，当业务发展到＿定规模后，往往会面临业务种类繁多、业务高度依赖的问题。而随着业务的发展’企业内的部门会越来越多，分工越来越细’部门之间的依存度和沟通成本也会越来越高。

   如果缺乏企业级总体规划，缺乏应对市场变化的快速反应能力和高效支撑商业模式创
   新的机制，企业运营和创新的成本将会大大增加

   为了提高市场‖阿应能力，解决商业模式创新问题’越来越多的企业开始尝试数字化
   转删。

6. 传统企业数字化转型的问题 ：

   过去这十年’移动互联等新型电商模式以及客户消费行为和习惯的改变，极大地刺激和影响了传统企业固有的业务形态和商业模式。传统企业从封闭走向开放，借鉴互联网企业的成功经验’开始积极融人互联网商业生态圈。但由于历史［泵因’传统企业背负了太多的技术债’长期的技术停滞导致技术能力严重 落后，同时企业内各部门之间坚实的“部门墙，，’业务与技术之间的鸿沟’也给企业数字化
   转型带来不小的困难。综合来看，传统企业数字化转型需要重点解决以下几个问题。

   • 技术体系落后的问题
     传统企业大多采用集中式架构，技术体系相对落后，可扩展能力不强。集中式架构过于依赖设备资源，基于稳定或性能考虑’大多运行在大型机或小型机上。同时’传统企业多采用“两地三中心”的容灾模式’高可用能力不强，难以实现多中心多活，也容易带来资源浪费的问题。
     在运维能力上，过于依赖人工，难以实现自动化运维，面对突发高频访问的业务场景不能实现自动弹性伸缩。当业务量到达一定规模后，集中式数据库的容量利性能问题也容易成为业务发展的瓶颈。
     总而言之’传统的集中式架构技术体系已经难以适应新形式下的业务发展要求
   • 单体架构的问题
     集中式单体应用往往会将多个功能放到一个应用中，经过日积月累，这个应用就会变成—个庞大而复杂的‘怪物”。随着项日团队成员的更替’时间一长就很少有人能完全搞懂这些代码之间的逻辑关系了。有些人可能会因为担心修改遗留代码而出现不可预知的Bug‖而宁愿增加大丘不必要的代码’这样会导致应用越来越庞大，越来越复杂，可读性越来越差，最终陷入恶性循环。对于整个项目团队来说’系统研发工作变成了一件极其痛苦的事情。
     除了代码，单体应用还存在诸多问题。由于单体应用的各个模块之｜司耀合度高’很可能因为一个局部的小Bug，而导致整个单体应用不可用。另外，单体应用部署包过于庞大’难以上云实现资源的弹性扩缩，导致应用扩展能力差且资源利用率不高。同时’单体应用作为一个整体’也难以完成局部功能的技术升级。企业难以尝试新的技术，以至干技术能力＝直停滞不前，无法及时完成技术升级，导致技术债越积越多。
   • 研发租运维能力落后的问题
     —般单体应用的项目团队的规模较大，通常采用传统的瀑布开发模式。这种开发模式的弊端在于开发和测试周期耗时长，交付质量和周期难以保证’不能实现持续快速交付，对业务需求和市场的响应能力柜对较慢’难以实施敏捷开发。
     另外’云计算平台和自动化运维工具对单体应用的生态支持右限，应用的部署和运维过程相对复杂。当应用出现问题时，基本靠人肉排查，且研发团队与运维团队难以快速定位和协同解决问题。
   • IT能力重复建设的问题
     为了支持企业内部业务发展’传统企业大多建设了一套集中式架构的单体核心系统。而近十年来，随着互联网电商业务的快速发展，很多传统企业既要维持传统业务’义要面向移动互联网生态圈开拓新业务。由干传统集中式技术体系和研发模式难以支持互联网海量高并发的业务要求，为了避免传统核心与移动互联应用之间的相互影响’不少企业在传统核心应用之外，采用分布式技术体系建设了移动互联应用，但由于两者销售同质产品，在基本功能模块k存在交集，这样就出现了重复造轮子的问题。
     除了传统核心应用和移动互联应用的重复建设外，在不同的业务场景或渠道也出现了业务同质化的怔题。这些存在同质业务的不同渠道’可能也是重复建设的重灾区。
     另外’在集团内部，由于缺少IT建设总体规划，不同子公司之间的公共业务能力（如客户等）的重复建设问题可能会更加突出。
     所以很多传统企业出现了关于“双核心”或‘稳敏双态”的争论。那么，为什么这类问题主要出在传统企业，而没有出现在新型互联网企业呢?
     我认为其根本原因是: ”传统的技术体系、研发模式以及业务模型难以同时处理传统和移动互联业务发展的矛盾。”
     综上，要解决IT重复建设的问题’就要从提升技术能力利重构业务模型人手，实现企业级业务能力的复用，这也是传统企业中台数字化转型呕需重点解决的问题。

7. 领域层代码结构

   • 请假微服务领域层有请假和人员两个聚合。请假和人元代码分别放在各自聚合所在的目录结构中。如果随着业务发展，人员相关功能需要从请假微服务中拆分出来，我们只需将人员聚合代码目录整体拆迁出来，独立部署，即可快速发布为新的人员微服务。

8. 微服务设计和开发时，要时时刻刻想着微服务的架构的演进，需要考虑聚合的解耦和未来聚合的重组。解耦后，微服务的边界就会更加清晰，更容易适应业务的快速变化，轻松实现微服务架构演进，自然就可以更快地响应前台业务需求的变化。

9. 实例：中台战略下的保险订单化设计。深刻理解基于DDD的中台建设核心知识体系和设计思想