这将是一个关于这本书的印象的故事，以及一些由于这本书而得以研究的概念和知识
建筑学
您能否阅读此出版物，对问题“建筑是什么”给出明确答案。 在编程和设计方面的架构是什么？ 她扮演什么角色？ 这个词有很多歧义。 一切似乎都很清楚，但是某种程度上是抽象的，而且没有准确性。 Martin相信并且我同意他的观点，该应用程序包含两个部分：
- 行为（行为）-程序（组件，服务）执行的功能和任务。
- 体系结构-这个术语更多地是关于更改应用程序。
但是，即使应用程序很好地执行了应执行的任务，这也不意味着它具有良好的体系结构。 体系结构与应用程序行为无关。 架构与变更的便利有关，架构与部署的便利有关，架构与开发的独立性有关。 架构是关于团队中新人了解的速度
这是构建此架构的方法，如何摆脱PM或利益相关者对需求的微小更改而带来的麻烦：这就是本书所要讲述的
关于作者
在我谈论这本书之前，我想先谈谈自己。
目前，我是一名强大的初级开发人员，专门研究通过ASP .NET CORE开发服务。
我已经在一个“画廊”上工作了一年，而且我似乎在做些事情
我已经读过两本书了，我建议大家阅读：
- 嵌入式系统的开发商；
- 前锋;
- 背书;
- 甚至是devopsam。
通常，对于至少与PP开发有某种联系的任何人，我的意思是这里不考虑不同的Saylov和PM'ov的直接开发（尽管了解为什么女仆有时花2倍的时间来完成任务也很有用），我建议您阅读这本书。
现在，我将尝试争论为什么我会这样认为
关于本书作者的一些知识（因为对我而言，作家的权威起着重要作用）。 我想您会理解我的，尽管这并不总是正确的，但是如果该领域的权威人士对您说些什么，您就会对他的讲话更有信心。 例如，我认为您宁愿相信医生给您的诊断，也不愿接受人群中某些人的诊断（谷歌症状）
自1970年以来，Robert Martin（又名Ankle Bob（叔叔Bob））一直从事编程领域以及各种系统（从Web服务到嵌入系统）的工作。 他是一名技术顾问和架构师，他在各种技术杂志上撰文，他是一位非常有经验的程序员，并且是在创建众所周知的SOLID原则（您可以说是创建者）中扮演着关键角色之一的人。 另外，我想补充一下，我有15年以上经验的团队负责人在这本书上为我提供了建议
关于这本书
依存关系
在阅读本书之前，我在同一本《哈布雷》上读了很多文章，其中出现了“依赖”一词。 这是什么，谁依赖谁，“依赖”到底是什么意思，某个阶级如何依赖某人？
在阅读本书时，我学到了两点：
依赖是一个术语，意思是某个类（组件，服务）知道某些其他类（组件，服务），并且在代码级别的这种知识是由某个命名空间导入确定的（现在，javists，sharpists，sishniks将理解我）。 。 换句话说：您有一个类A，其名称空间为Default.Classes，而类B为Another.Classes。 因此，如果使用Another.Classes出现A类代码； -这意味着A类取决于B类。
要根据该方案理解从属类在哪里，从属类在哪里-看看箭头的方向：1）箭头将从类A指向类B的方向。这意味着类B比类A更独立。并且类A的更改，对B级没有“损害”
实心
读这本书的主要原因之一是从原始资料中解释了SOLID原理，因为Rob叔叔开发了这些原理，我们可以说，由于他，我们听到了这个名字-SOLID。
对于那些不知道的人，请遵循以下原则，并建议按照以下5条规则设计其应用程序：
S-SRP（单一责任原则）
O-OCP（开闭原理）
L-LSP（Liskov替代原理）
I-ISP（接口隔离原理）
D-DIP（依赖性反转原理）
所有这些原理都可以应用于类和对象的级别，模块和组件的级别以及导轨（服务）的级别。
如果您认为“单一责任”原则是关于类或模块只能做一件事的事实，那么您绝对应该至少阅读有关Solid的章节。 因为上面给出的定义是结果，但不是原理本身的定义
关于依赖倒置
我要特别注意对依赖倒置原则（D来自SOLID的解释）的解释。 在阅读本书的过程中，我了解到这不仅是一个原则，还是一种机制和工具，您可以使用该机制和工具来更改依赖关系的方向，并使业务逻辑（DOMAIN）与数据访问层的实现细节无关。 （达拉）
尽管原理本身以及SOLID中的其他原理除机制之外还有其他含义，但该机制本身在整本书中都已使用，这是反转和更改依赖关系方向的主要方法之一，顺便将其与DDD一起使用。
关于制定架构决策
这本书经常会提到做出重要架构决策的原则：使用哪个数据库，使用哪个框架，连接哪个库，用作搜索引擎的内容，等等。
因此，作者认为：您应该尽快做出这种决定。 由于需求可能会发生变化，性能也会受到限制，因此行为组件本身也会发生变化。 在开发过程中，某些解决方案似乎不那么有效，也不那么方便。 而架构的强弱将决定您可以用多快又不费力地将一种技术替换为另一种技术（OCP这样说）。
例如，突然之间，您决定使用MongoDb代替Postgresql或一般文件，或者使用模拟数据，这些操作将在内存中执行。 在某些情况下-这可能使重写几乎所有逻辑成为可能。
为了防止这种情况，我们可以使用一些机制来尽可能延长决策时间。 这些机制之一是抽象。
DDD参考
DDD-域驱动设计-一种开发具有复杂业务逻辑（对变更至关重要）的服务的方法，旨在通过赛艇运动员最大程度地了解项目管理职位（采购经理，销售经理等）。 也就是说，所有项目成员之间将存在一种普遍存在的语言，并且每个人都可以理解对方，并且每个人都在同一领域中以相同的业务规则进行思考。
如果您是DDD的支持者，或者想成为DDD的支持者，或者您不了解此事，但想了解，那本书是必读的，尤其是本书的第二部分。
在这里，作者解释了依赖关系规则的存在，以及为什么遵循它，您将构建正确的应用程序体系结构。 为什么依赖关系应遵循High Policy组件，为什么域（High Policy组件）应独立于基础结构以及它如何为您简化部署和开发
抽象化
Rob叔叔还谈到了实施细节如何损害您的系统，并防止系统日后发展。
记住！
DB是实现细节
客户端（网络，移动等）-实施详细信息
框架是实现细节。
使用上面描述的具有接口和抽象的依赖倒置，依赖规则和其他机制，有必要尽可能多地抽象而不依赖它
构建模块的方法
作为ASP .NET CORE上的服务开发人员，我特别喜欢本部分。 因为它描述了从现成的组件构建统一服务体系结构的方法。
Robert描述了4种可能的层分离方案。
他明确指出了为什么三层体系结构中经常使用的机制：UI（控制器），Services（域），DAL（数据库）与其他相比足够糟糕。 我没有看到很多项目，但是在每个后端（例如微服务）中，它都使用三层体系结构。
同样，经常使用单组件一服务架构。 通常，它们都很好，但是相比之下，它有很多缺点，例如，如何使用DDD构建体系结构，尤其是在对变更至关重要的情况下，以及复杂的服务。
总的来说，对本书的评论已经结束。 我真的很喜欢这本书本身，感谢作者，我不后悔阅读的内容。 亲爱的读者，感谢您的关注，请不要严格判断-本出版物是根据书的印象和我的个人热情而定
更新1.0
在讨论过程中，可以理解，突然而轻松地改变存储方式并非易事。 在某些情况下，即使是非常痛苦但又抽象化和封装的存储访问，也令人怀疑是什么使情况变得更糟，但情况会好一些，至少由于可变组件与其余组件无关。