架构整洁之道（CleanArchitecture）与领域模型与领域驱动设
计（DDD）
架构整洁之道 (Clean Architecture )与领域模型与领域驱动设计(DDD)
领域模型与领域驱动设计(DDD)
领域模型(Domain Model)
解决什么问题
问题域
需求分析
分析理解复杂业务领域问题
准确反映业务语⾔
是什么
商业建模
企业的业务模型
⾏业的业务模型
业务中涉及到的实体及其相互之间的关系
领域驱动设计(Domain-Driven Design)
概述
将复杂的问题域划分为单独的块（称为有界上下⽂），虽然有很多⽅式如：不同的⼼智Mental模式，组织政治，域语⾔学等也是这样做，但是DDD建⽴了⼀个有界的⼼智mental模式，这样商务⼈⼠也可以理解，程序员也可以很容易地在代码中实现。
CQRS，作为⼀种战术办法，是实现DDD建模领域的最佳途径之⼀。
"⾎量"多少
失⾎模型
传统J2EE或Spring+Hibernate等事务性编程模型只关⼼数据，这些数据对象除了简单setter/getter⽅法外，没有任何业务⽅法，被⽐喻成失⾎模型
贫⾎模型
充⾎模型
让过去被肢解被⿊crack的业务模型回归正常
"世界观"
接触到需求第⼀步就是考虑领域模型，⽽不是将其切割成数据和⾏为，然后数据⽤数据库实现，⾏为使⽤服务实现，最后造成需求的⾸肢分离。DDD让你⾸先考虑的是业务语⾔，⽽不是数据。重点不同导致编程世界观不同。
"演员们"
业务实体属性
业务实体的关系
服务
服务与实体的关系
落地实现
in-memory缓存
当建⽴⼀个⼤型Java应⽤时，引起性能问题⼤部分是延迟，延迟是指请求和响应之间的时间差，在⼀个分布式Java系统中引起延迟的原因有：
问题背景
从磁盘上加装数据的IO延迟 跨⽹络加装数据的IO延迟 在分布式锁上的资源争夺 垃圾回收引起的暂停 - 内存缓存 - 内存是快的: 为了⾼性能，你需要在内存中处理数据。 ⽹络是慢的: 通过⽹络传输数据会严重影响性能，包括数据库连接池。 在许多应⽤中，应⽤的快速性能与数据实时更新需要寻⼀个平衡点 - 内存缓存原来作⽤是提⾼数据库访问性能。但是缓存不是数据库遮羞布，架构上缓存引⼊有着重要意义：状态对象：数据库的替代者。
缓存实际是内存，将状态置于内存⽽不是数据库，不但性能提升，还提⾼软件的可伸缩性和扩展性，
直⾄轻松发展为分布式系统或云计算，这种缓存称为内存缓存(in-memory cache)或称 数据⽹格In-Memory-Data-Grid (IMDG) - 当我们将DDD领域模型加载到内存中以后，我们就不再⾯向关系数据库中数据表编程，⽽是真正直接⾯向模型对象编程。
CQRS
数据的查询
数据的新增修改删除等动作
命令查询的责任分离Command Query Responsibility Segregation (简称CQRS)
能够使改变模型的状态的命令和模型状态的查询实现分离
Command
Query
DCI
DCI可以说是函数式functional编程⽐如Scala带来的⼀个理念.
⾯向组合编程
数据Data 场景Context 交互Interactions的简称，DCI是⼀种特别关注⾏为的模式(可以对应GoF⾏为模式)，⽽MVC模式是⼀种结构性模式，MVC模式由于结构化，⽽可能忽视了⾏为事件。
Data: 对象的数据
Context: 对象使⽤的场景
Interaction: 对象的交互⾏为
将“是什么”和“做什么”进⾏分离
桥模式
Use Case scenario
理念起源
EDA 或 Event Source
事件驱动有以下特征：
以事件为驱动的编程模型
以事件为媒介，实现组件或服务之间解耦
传统⾯向接⼝编程是以接⼝为媒介，实现调⽤接⼝者和接⼝实现者之间的解耦，但是这种解耦程度不是很⾼，如果接⼝发⽣变化，双⽅代码都需要变动，⽽事件驱动则是调⽤者和被调⽤者互相不知道对⽅，两者只和中间消息队列耦合。
是什么
特征
⽣产者producer发⽣实时事件 推送通知 ⽣产者发射即完成fire-and -orget 消费者consumer⽴即响应 事件与命令是有区别的
分层架构
三层模型
表现层
业务层
负责表达业务领域概念、业务状态以及业务规则
OO设计原则和设计模式
scala不是内部或外部命令负责完成功能，并且协调丰富的领域对象来实现功能，不能包括业务规则，⽆业务状态
应⽤层
领域层
持久层
层与层之间的规则
每个层都是内聚的，并且只依赖它的下层，为了实现各层的最⼤解耦，IOC/DI容器是当前Java业务层的最好选择 。
架构整洁之道
  ⼜称⼲净的架构The Clean Architecture，这是著名软件⼯程⼤师Robert C Martin提出的⼀种架构整洁清晰之道，也是当前各种语⾔开发的⽬标架构。⼲净、清晰、整洁的架构应该只包含单向的依赖关系，这样才可以在逻辑上形成⼀种向上的抽象系统。
我们经常听说过如下各种架构：
六边形架构Hexagonal Architecture (也称为 端⼝和适配器) 这是由Alistair Cockburn 提出，被Steve Freeman和 Nat Pryce在他们的书籍Growing Object Oriented Software中采取的。
多年来，软件应⽤程序的⼀个重要问题是将业务逻辑渗透到⽤户界⾯代码中。这导致的问题有三个：
⾸先，系统⽆法⽤⾃动化测试套件进⾏整齐测试，因为需要测试的部分逻辑依赖于不断变化的视觉细节，如字段⼤⼩和按钮位置;
出于同样的原因，不可能从⼈为驱动的系统使⽤转变为批量运⾏系统;
出于同样的原因，当程序变得有吸引⼒时，很难或不可能允许程序由另⼀程序驱动。
在许多组织中重复使⽤的尝试解决⽅案是在架构中创建⼀个新层，并承诺这⼀次，真实⽽真实地，没有业务逻辑将被放⼊新层。但是，由于没有机制来检测违反该承诺的时间，组织⼏年后发现新层混乱了业务逻辑并且旧问题再次出现。
Hexagonal Architecture(六⾓形或六边形) 于2005年由Alistair Cockburn撰写，是⼀个具有许多优势的软件架构，⾃2015年以来⼜重新引起了⼈们的兴趣。
六边架构的初衷是：
允许应⽤程序同样由⽤户，程序，⾃动化测试或批处理脚本驱动，并与最终的运⾏时设备和数据库隔离开发和测试。
六⾓形架构允许隔离应⽤程序的核⼼业务，并⾃动测试其⾏为，⽽不依赖于其他任何事情。这可能是该架构引起域驱动设计（DDD）从业者关注的原因。但要⼩⼼，DDD和六边形结构是两个相当不同的概念，它们可以相互加强，但不⼀定⼀起使⽤。
最后，这种架构设置起来并不复杂。它基于⼀些简单的规则和原则。让我们探索这些原则，看看它们在实践中的含义。
六⾓架构原理
六边形体系结构基于三个原则和技术：
明确区分应⽤程序，领域和基础结构三个层
依赖关系是从应⽤程序和基础结构再到领域
我们使⽤端⼝和适配器隔离它们的边界
1. 原则：独⽴的应⽤程序，域和基础结构三个层
第⼀个原则是明确地将代码分成三个⼤层。
左侧Application是应⽤程序端
这是⽤户或外部程序与应⽤程序交互的⼀⾯。它包含允许这些交互的代码。通常，您的⽤户界⾯代码，API的HTTP路由，以及使⽤您的应⽤程序的程序的JSON序列化都在这⾥。(banq注：Spring Boot的控制器)
这⾥也是Actor⾓⾊驱动领域所在。注意：Alistair Cockburn谈的是应⽤程序⽅⾯的左侧或⽤户侧。
领域层Domain中⼼位置
通过领域层隔离左侧和右侧。它包含所有关注和实现业务逻辑的代码。业务词汇和纯粹的业务逻辑。
右侧基础设施层
在这⾥，我们可以到您的应⽤程序需要什么，它驱动哪些组件进⾏⼯作。它包含必要的基础结构详细信息，例如与数据库交互的代码，调⽤⽂件系统或处理对您所依赖的其他应⽤程序的HTTP调⽤的代码（集成）。
以下原则将实现在应⽤程序，域和基础结构之间实现逻辑分层。
这种分离的第⼀个重要特征是它将问题分开。在任何时候，您都可以选择专注于某个逻辑，⼏乎独⽴于其他两个逻辑：应⽤程序的逻辑，业务的逻辑或基础架构的逻辑。它们在不混合的情况下更容易理解，并且每个逻辑的约束对其他逻辑的影响较⼩。
另⼀个特点是我们将业务逻辑放在代码的最前端。它可以在⽬录或模块中隔离，以使其对所有开发⼈员都明确。它可以在不承担程序其余部分的认知负荷的情况下进⾏定义，改进和测试。这很重要，因为最终，开发⼈员对⽣产中的业务有了解。
带适配器的六边形架构
Onion Architecture 作者Jeffrey Palermo
写出⾼质量软件是困难和复杂的：不仅仅是为了满⾜需求，还应该是健壮的，可维护的，可测试的，并且⾜够灵活以适应成长和变化。这就是洋葱架构出现的原因，它代表⼀组优秀的开发实践，⽤来开
发任何的软件应⽤都是⼀个不错的⽅式。
洋葱架构，也成为整洁架构（The Clean Architecture）,⽤来构建具有如下特点的系统：
1.    独⽴的Frameworks
2.    可测试
3.    独⽴的UI
4.    独⽴的数据库
5.    独⽴的任意外部服务（代理）
看到这张图，你应该能理解为什么称其为洋葱架构了.
依赖原则（The dependency rules）
上⾯的同⼼圆代表软件的不同部分。总得来说，越往⾥⾯，代码级别越⾼。外层的圆是（实现）机制，⽽内层的圆是原则（Policies）。
让这个架构起作⽤的最主要原则是依赖原则。这个原则要求源码依赖只能指向内部。内部的圆不能知道外圆的任何事情。⼀般来说，外圆的声明（包括⽅法、类、变量或任何软件实体）不能被内圆引⽤。
同样的，外圆使⽤的数据格式不能被内圆使⽤，尤其是外圆中的Framework产⽣的格式。我们不想让外圆的任何东西影响内圆。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。