.NET整洁架构之道 [意]迪诺·埃斯波西托整洁架构 .NET 软件架构架构师成长_[意]迪诺·埃斯波西托_9787111789895

本书分为三部分。第一部分为理论，为软件模块化奠定了基础，追溯了软件架构的历史，并总结了领域驱动设计（DDD）的要点——这是一种非常有助于拆解业务领域的方法，尽管在项目中并非必要。第二部分为实现，讲述了构成“整洁”架构的五个层。这部分的重点并不在于架构的同心圆形式，这种形式已经被大量的书籍和文章所普及，而在于各个构成层次所提供的实际价值：表示层、应用层、领域层、领域服务层和基础设施层。第三部分为应用，主要关注三个经常遇到的话题：是选择单体应用还是微服务，是选择客户端渲染还是服务器端渲染，以及技术债务和技术信用。

1990年夏，我毕业于计算机科学专业。那个时候，在欧洲，可以学习计算机相关专业的地方寥寥无几。学校里并没有独立的计算机学院，计算机科学是数学、物理和自然科学等更传统学科的延伸。在20世纪90年代，那些计算机领域的专家被视为神奇的存在—他们广受欢迎，但职业发展路径却不甚明朗。我最初从事Windows开发工作。当时，计算机杂志极受追捧，人们每个月都满怀期待地等待新一期的发行。我梦想着能为这些杂志撰稿。我曾有幸获得了一次这样的机会，并且乐此不疲，以至于30年后的今天我还在从事这项工作。我热衷于知识分享，以至于在我第一份正式开发工作结束的五年里，它成了我的主要职业。在接下来的二十多年里，我的生活几乎就是撰写书籍和文章、在会议上发言、授课，以及偶尔提供咨询服务。直至2020年，我接触到的实际开发中的代码和日常开发的机会都极其有限。尽管如此，我还是为那些参与实际项目的人成功地编写了多本参考书籍。然而，在我内心深处，仍旧萦绕着一个难解的疑问：我仅仅是一个擅长讲授的专业人士，还是也能成为实践者呢？我是否有能力构建一个实际应用的系统呢？环境及其他生活上的变故最终帮我找到了答案。我面临着一项艰巨的任务，那就是在原本计划时间的一小部分内构建一个庞大而复杂的系统，而变故又大幅缩短了这一时间。这期间，我对系统设计、敏捷开发、进行测试和规划都显得力不从心—唯一确定的就是截止日期。我采取了行动，并按照我多年来在教学中探索和实践的路径。这种做法证明是成功的。不止如此，在这个过程中，我意识到我构建软件的方式及其相关模式实际上被称为“整洁架构”。本书汇集了我在过去二十多年间的学习、教授和咨询知识，以及最近三年在软件开发实践中的核心经验。我所在公司中的几位开发者都是从初级职位起步的，他们通过使用和实践本书中的内容得到了成长。我希望本书对你同样有所帮助！本书读者对象本书主要面向软件专业人士，包括架构师、首席开发人员，以及我特别要提到的.NET应用程序的开发者。每个想成为软件架构师的人都会从本书中受益匪浅。而且，真正合格的架构师，大多是从开发者成长起来的。我坚信，打造卓越软件的关键在于优秀的开发者，而优秀的开发者则源自优秀教师的悉心教导、良好榜样的积极引领，以及—但愿如此—优秀的书籍和课程的滋养。本书所有章节都带有.NET特色，且大多数内容对任何软件专业人士来说都是易于理解且有用的。阅读本书所需的知识阅读本书，希望你至少对.NET开发和面向对象编程概念有最基本的了解。如果你对使用.NET平台有良好的基础，并且了解一些数据访问技术，那么这将对你阅读本书有所帮助。这不是一本关于抽象设计概念的书，也不是一本充满交叉引用或者在方括号中使用花哨字符串链接到书末参考文献中某篇旧论文的经典架构书。这是一本关于在21世纪20年代建立系统并面对21世纪20年代困境的书，从前端到后端，包含云平台和可扩展性问题。本书适合的场景如果你正在寻找一本参考书，或者想要了解如何使用某种模式或技术，那么本书可能不适合你。相反，本书的目标是分享和传递知识，让你在任何时候都知道该怎么做。或者至少，你现在知道在类似情况下，其他人—Dino和他的团队—是怎么做的。本书组织结构总的来说，现代软件架构只有一个前提条件：模块化。无论你采用分布式、面向服务的结构，还是微服务碎片化模式，或是紧凑的单体应用，模块化都是构建和管理代码库，以及根据业务需求进一步增强应用的关键。如果没有模块化，你可能只能一次性交付一个能够运行的系统，但是要扩展和更新它就会变得很困难。本书第一部分为理论，为软件模块化奠定了基础，追溯了软件架构的历史，并总结了领域驱动设计（Domain-Driven Design，DDD）的要点—这是一种非常有助于拆解业务领域的方法，尽管在项目中并非绝对必要。第二部分为实现，讲述了在本书的视角中构成“整洁”架构的五个层。这部分的重点并不在于架构的同心圆形式（这种形式在大量的书籍和文章中很常见），而在于表示层、应用层、领域层、领域服务层和基础设施层所提供的实际价值。第三部分为应用，主要关注三个经常遇到的话题：是选择单体应用还是微服务，是选择客户端渲染还是服务器端渲染，以及技术债务和技术信用。本书配套代码本书的第二部分描述了一个名为Renoir项目的参考应用程序，其全部代码都可以在GitHub上找到：https://github.com/Youbiquitous/project-renoir源代码的压缩版本也可以在MicrosoftPressStore.com/NET/download上下载。提示这个参考应用程序需要.NET 8，并且是一个带有Blazor前端的ASP.NET应用程序。它使用Entity Framework进行数据访问，并假设有一个SQL Server（任何版本）数据库。

译者序前言致谢第一部分　理论第1章　模块化软件架构的历史和演变　　21.1　模块化三层架构　　31.1.1　三层架构的主要特点　　41.1.2　逻辑层、物理层和模块化　　61.2　DDD的典型架构　　81.2.1　DDD配套的支持架构　　81.2.2　其他补充　　111.3　不同类型的分层架构　　151.3.1　六边形架构　　151.3.2　整洁架构　　161.3.3　特性驱动架构　　171.4　本章小结　　19第2章　DDD的核心精髓　　202.1　DDD简介　　212.1.1　战略分析　　212.1.2　战术设计　　232.1.3　DDD的误解　　242.1.4　战略设计工具　　262.2　UL　　262.2.1　领域语言术语表　　272.2.2　构建术语表　　282.2.3　保持业务和代码的一致性　　302.3　限界上下文　　332.3.1　处理歧义　　342.3.2　设计限界上下文　　362.4　上下文映射　　392.4.1　上游和下游　　392.4.2　上下文映射示例　　402.4.3　部署映射示例　　412.5　本章小结　　42第3章　模块化设计的基础　　433.1　模块化设计的要素与原则　　443.1.1　SoC　　443.1.2　松耦合　　453.1.3　可复用性　　453.1.4　依赖项管理　　463.1.5　文档　　463.1.6　可测试性　　463.2　应用模块化设计　　473.2.1　表示层：与外界交互　　473.2.2　应用层：处理接收到的指令　　483.2.3　领域层：表示领域实体　　483.2.4　数据/基础设施层：持久化数据　　483.3　实现模块化　　483.3.1　在单体中增添模块化设计　　493.3.2　微服务简介　　503.4　最简方案原则　　523.4.1　可维护性　　533.4.2　可测试性　　543.5　本章小结　　56第二部分　实现第4章　表示层　　604.1　Renoir项目：最终目标　　614.1.1　应用程序介绍　　614.1.2　抽象上下文映射　　634.1.3　物理上下文映射　　664.2　业务需求工程　　694.2.1　分解软件项目　　704.2.2　基于事件的故事板　　704.2.3　Renoir项目的基本任务　　724.3　表示层的边界和部署　　734.3.1　敲开Web服务器的门　　744.3.2　ASP.NET应用程序端点　　754.4　表示层开发　　764.4.1　连接到业务工作流　　764.4.2　前端及相关技术　　814.4.3　纯API表示层　　824.5　本章小结　　83第5章　应用层　　855.1　Renoir项目架构图　　865.1.1　访问控制子系统　　865.1.2　文档管理子系统　　885.1.3　在Visual Studio中打开Renoir项目　　895.2　任务编排　　905.2.1　任务简介　　905.2.2　分布式任务示例　　915.2.3　Renoir项目中的任务示例　　935.3　数据传输　　935.3.1　从表示层到应用层　　945.3.2　从应用层到持久化层　　985.4　实现细节　　1005.4.1　应用层概要　　1015.4.2　应用程序设置　　1045.4.3　日志记录　　1085.4.4　处理和抛出异常　　1135.4.5　缓存及其模式　　1175.4.6　注入SignalR连接中心　　1215.5　应用层的边界和部署　　1235.5.1　依赖列表　　1235.5.2　部署选项　　1235.6　本章小结　　125第6章　领域层　　1266.1　分解领域层　　1266.1.1　业务领域模型　　1266.1.2　辅助领域服务　　1296.2　构建领域模型　　1316.2.1　将焦点从数据转向行为　　1316.2.2　领域模型的组成部分　　1346.2.3　Renoir项目的领域模型　　1386.3　领域漫游指南　　1396.3.1　治疗软件贫血症　　1406.3.2　实体类的共同特征　　1416.3.3　代码礼仪　　1446.3.4　代码风格规范　　1536.3.5　编写真正易读的代码　　1576.4　本章小结　　160第7章　领域服务层　　1617.1　领域服务的定义　　1627.1.1　领域服务的无状态特征　　1627.1.2　标记领域服务类别　　1627.1.3　领域服务和UL　　1637.1.4　领域服务的数据访问　　1637.1.5　领域服务的数据注入　　1647.2　常见的领域服务场景　　1647.2.1　确定客户的忠诚度状态　　1647.2.2　领域事件　　1657.2.3　发送业务邮件　　1667.2.4　为密码加密服务　　1677.3　具体实现　　1687.3.1　领域服务的一个例子　　1687.3.2　有用且相关的模式　　1707.3.3　REPR模式　　1717.4　其他问题　　1767.4.1　领域服务是否有必要　　1767.4.2　领域服务的其他应用场景　　1787.5　本章小结　　179第8章　基础设施层　　1808.1　基础设施层的职责　　1818.1.1　数据持久化和存储　　1818.1.2　与外部服务的通信　　1828.1.3　与内部服务的通信　　1828.2　实现持久化层　　1838.2.1　仓库类　　1848.2.2　使用EF Core　　1888.2.3　使用Dapper　　1968.2.4　在数据库中托管业务逻辑　　1978.3　数据存储架构　　1998.3.1　介绍命令/查询分离　　1998.3.2　ES执行摘要　　2038.4　本章小结　　204第三部分　应用第9章　微服务和模块化单体架构　　2069.1　远离遗留的单体系统　　2079.1.1　并非所有单体架构都是糟糕的　　2079.1.2　单体架构的潜在缺点　　2089.2　关于微服务　　2109.2.1　早期采用者　　2119.2.2　微服务架构和SOA的原则　　2119.2.3　微服务的“微”到底有多微　　2129.2.4　微服务的优点　　2149.2.5　微服务的缺点　　2159.3　微服务是否适用于所有应用程序　　2229.3.1　大型企业的一个大误解　　2229.3.2　SOA和微服务　　2239.3.3　微服务是否适合你的场景　　2249.3.4　规划和部署　　2279.4　模块化单体　　2319.4.1　适用于新项目的架构　　2329.4.2　模块化单体策略更适用于新项目　　2329.4.3　从模块到微服务　　2359.5　本章小结　　238第10章　客户端渲染和服务器端渲染　　23910.1　Web应用程序简史　　24010.1.1　史前时代　　24010.1.2　服务器端脚本时代　　24210.1.3　客户端脚本时代　　24410.2　客户端渲染　　24610.2.1　HTML层　　24710.2.2　API层　　25010.2.3　迈向更现代的史前时代　　25310.3　SSR　　25710.3.1　前后端分离　　25810.3.2　ASP.NET前端选项　　25910.3.3　ASP.NET Core与Node.js的对比　　26210.3.4　阻塞式/非阻塞式传说　　26510.4　本章小结　　267第11章　技术债务与技术信用　　26811.1　技术债务的隐藏成本　　26911.1.1　处理技术债务　　26911.1.2　解决债务的方法　　27111.1.3　会放大债务的行为　　27311.2　技术信用的隐藏收益　　27511.2.1　破窗理论　　27611.2.2　重构　　27811.2.3　做正确的事情　　28011.3　本章小结　　281

你还可能感兴趣

我要评论