目录
- POP
- OOP
- AOP-untity的AOP实现
- DDD
- 总结
1:POP:面向过程编码,一路执行下去,不好扩展。
2;OOP：--应对复杂设计
1.编码前,把需求以对象维度去拆分
2.功能怎么产生的？对象与对象之间的交互,就是类与类之间的依赖
3.所以只要交互的接口不变,这样对象内部的变化不影响其他对象
4.并且可以把一个整体功能的拆分成对象 来进行细化,对象直接也可以重用
5.基于类来做的,但是也局限于类
封装:1. 就是确定好这个对象的行为(业务逻辑)=对象的确定,隔离好内部的业务逻辑之后 就不用去操心外部的实现
2.数据安全,可以通过不同级别的访问修饰符如public private等 限定外部是否调用
3:降低耦合,以前是面向过程 现在是对象与对象之间
4.提高重用,对象重用
继承:子类继承父类,子类拥有父类的一切,任何父类出现的地方都可以被子类替代
1.代码重用
2.单基类继承:只能有一个父类
3.继承之后会有重写 覆写() 重载(方法签名一样,方法参数列表不一样)
4.子类继承父类之后,为什么父类实例化的时候,可以使用子类实例化,？是因为子类继承父类后，默认有一个无参构造函数继承:base(指向父类),这样构造子类之前先去执行构造父类
多态:
1.继承后多态:一个父类,可以被多个子类继承,每个子类拥有自己不同的方法
2.运行时多态：虚方法:父类必须包含实现,但可以被重载,覆写(子类继承父类的虚方法之后加了new,隐藏子类方法,在运行时任然会执行父类方法)
3.抽象方法,子类继承后必须重写
3.AOP:面向切面编程,在执行一个oop方法之前或之后,动态的新增功能,不影响oop原先的方法
#OOP造房子: 类>类库>架构>系统 房子》一层楼》梁柱》大厦 大厦的稳定需要房子不能随便去拆,但是现实中的需求是不断变更的,这就矛盾了
#AOP就是来解决上面不稳定的问题,AOP可以动态的改变OO的模型,相当于你要在装修房子的时候,动态的提前给你装修前做好工作,让你不再装修房子,保持稳定
.Unity使用AOP简单3步
#第一:先增加3个引用
1. Unity 2.Unity.Interception 3.Unity.Interception.configuration(用来读取配置文件的)
#2.增加配置文件---配置文件配置的是相关类的实现，相关类的实现必须要实现这个IInterceptionBehavior接口，实现方法
#3.执行---按照配置文件配置的顺序执行；
#MVC中的AOP实现是通过特性标识来支持AOP，五大过滤器,Authiretion...
4.DDD领域驱动设计-为了应对更加复杂开发而设计
1：DDD为什么而诞生：为了降低沟通成本 不同人工种 用同一种方式来解决沟通
2：OOP-也有一定的局限性,比如建一层楼,可以把楼拆分成 砖,工人,支柱等对象, 但是一层大厦,小区,城市,这样就超过OOP的边际了
3：DDD-最近火起来的原因就是和微服务很搭配 因为微服务落地就是要合理的业务拆分,高内聚,低耦合,避免重复调用
4：领域由谁来划分，相关业务的领域专家,就比如做智能车系统,就需要搞智能车的技师来划分这个领域,因为我们开发不知道汽车到底有多少个零件
5：划分好领域只考虑业务, 领域由业务设计好之后, 再由领域驱动开发,只要成功完成每个领域,最后领域组装成的系统就不会变形
如何落地DDD：理解领域 拆分领域,细化领域
5.总结：
pop-无边界
oop-以对象为边界(被类束缚了)
DDD-扩大边界(问题域为边界),将对象组成领域,只是一种程序分析设计方法,具体的代码实现最终依靠的还是oop和AOP
以前开发模式;需求-数据怎么入库-逻辑开发-ui界面-完成(这个流程中间很容易因为需求变动导致后面从数据入库开始就大变)
领域模式：只分析业务(前期只了解业务需求,不考虑任何开发技术)-再考虑实现-避免改动,这样下来,做的东西完成以业务为主 业务给什么样,最后做出的就是什么样子
DDD和原本的三层架构区别
三层架构ui:负责界面展示 >bll:业务逻辑>DLL,基础数据层
DDD: 箭头表示调用
6.如何实现DDD的拆分
User Interface-用户层: 用户>应用(复杂逻辑,) 用户>领域 (简单业务逻辑) 用户>基础通常层(发邮件)
Applition-应用层:应用>领域（当业务复杂,ui需要调用多个Domain用这个来解耦）协调组装让用户调用领域
Domain-领域层：核心业务逻辑，其实就是业务
Infrastructure基础通用层：日志,邮件共用的
-----------------------------------------------------------------------------------------------------------------------------------
-----------------------------------------------------------------------------------------------------------------------------------
类和类之间是以类作为边界的 而DDD怎么在代码里面实现边界划分的？
而DDD和以前ashx-实现IRequiredSession一样才可以使用某个方法
DDD和数据库的交互 是必须实现IAggrogatoRoot空接口标记-IRepository接口数据库访问实现
Add<T>()where:IAggreaateroot 就像这样 才可以使用数据库的增加方法 来达到领域边界
所以： 领域的边界就是：靠这个（IAggrogatoRoot）空接口泛型约束来做限制
就像log领域 给他加上IAggrogatoRoot 变成了日志领域
-----------------------------------------------------------------------------------------------------------------------------------
领域事件：包含多个实体和对象,一次操作会触发不同对象的增删改-要保证事务性的话就是一起提交
就需要一个事件总线,也叫事件驱动-event
eventbus-事件总线-像一个容器,将不同的动作聚合在一起保存着,然后一次性执行
事件总线：其实就是只负责解耦,至于保证事务能成功和一致性则需要在事件总线上扩展需要的这些功能(和观察者模式差不多,就是个容器,解耦)
-----------------------------------------------------------------------------------------------------------------------------------
IRepository:仓储模式--数据访问层 区别于DAL
DAL：从数据出发 要什么表 就给什么表的增删查改
IRepository：没有数据库访问和实现, 为领域服务的,领域要什么,就实现什么 就是增删查改包了一层,要什么就给出什么。
为了让领域(业务)跟实现分离
UnitOfWork工作单元：一次性事务提交,实现上就是一个context，最后SaveChange一下(EF Core 提交一样)
-----------------------------------------------------------------------------------------------------------------------------------
Entity Object(EO):数据库层面, 数据库查出来的就是EO
DTO:数据传输对象,层与层之间传输的对象，按需传递,屏蔽数据库,需要automapper映射一次
ViewModel:和试图相关,绑定界面需要组合对象,需要再定义一次,就是MVC里面的对象 @Model（界面绑定的对象）
从数据库查出来 EO， 然后对象根据业务逻辑传遍到另外一层,就是DTO, DTO到界面可能有些字段要变动,就是VIewmodel，最终这个ViewModel就是给界面用的
-----------------------------------------------------------------------------------------------------------------------------------
设计领域模型的步骤()
1：建立初步的领域模型
2：叫领域专家分析这个软件主要有些什么功能
3：划分这些软件功能的领域模块, 每个模块应该放那个领域层,公共的放应用层
4：分析领域(业务)之间的关联,是1对1还是多对多,初步的领域模型以及好了
5：找出聚合边界及聚合根
6：为聚合根匹配仓储
7：走查场景-就是领域专家回归你的业务逻辑对不对
8：落体,考虑如何创建领域实体或值对象
9：再次梳理重构模型 因为项目没有一次到位