Automannn的学习园地

# OOP面向对象程序设计

  • Object-Oriented Programming面向对象编程
  • 基本思想是：计算机程序由单个能够起到子程序作用的单元或对象组合而成
  • OOP=对象+类+继承+多态+消息。其中核心概念是类和对象,主要特性是封装、继承、多态

# OOP架构

# MVC三层架构

  • M模型，V视图，C控制器
  • 目的是实现M和V的代码分离，从而使同一个程序可以使用不同的表现形式
  • MVC最开始存在于桌面程序中
  • 是二十世纪八十年代，为编程语言Smalltalk-80发明的一种软件设计模式,后来成为JAVA EE平台的设计模式

# MVC的痛点

  • 业务的交互主要分为两种：系统内交互与系统外交互。不管是系统内部交互、系统外部交互，逻辑都是按照功能点被杂糅在一起
  • service层利用DO,DTO,VO等业务POJO作为数据载体，完成了所有模型之间的逻辑处理、数据转换等跟业务有关或者无关的事情。

# 代码层面

  • 业务逻辑散落到service,可维护性越来越差
  • 面向数据库表编程，而非模型编程
  • 实体类之间的关系成了复杂的网状结构，成为大泥球，牵一发而动全身，导致不敢轻易改代码.
  • service类承接所有的业务逻辑，越来越臃肿，容易出现几千行的service类
  • 对外接口直接暴露实体模型，就算由DTO一般也是实体类的直接COPY
  • 外部依赖层直接从service层调用，字段转换、异常处理大量充斥在service方法中
  • 由于权责不明晰，除了常用的接口类，为了解耦而设置的接口类经常不知道往哪放

# 项目管理层面

  • 交付效率越来越低
  • 稳定性差：不好测试，代码改动的影响范围不好预估
  • 理解成本高：新成员介入成本高，老成员离职成本大

# MVC贫血模型

  • MVC的POJO，除了字段属性外，内部没有任何的业务逻辑

# DDD领域驱动设计

  • Domain-Driven Design,领域驱动设计，或者说业务驱动设计;

# 必要性

  • DDD强调先把领域中涉及到的数据、流程、规则等都弄明白了，然后为其建立模型，这个模型，决定了将用什么技术、什么架构、什么平台来实现这个系统
  • 对于项目的成败,技术不是决定性因素，领域模型是否符合事物的本质才是关键.
  • 领域驱动设计的出发点是业务导向，技术服务于业务.
  • 提倡以业务为核心，解耦外部依赖，分离业务复杂度和技术复杂度

# 充血模型

  • 建立领域模型形成聚合根，将原先散落在Service层的业务逻辑收拢到模型领域内部，聚合及业务
  • DDD价值观里面，系统内部任何业务都是某个业务领域模型的职责体现，将核心的业务逻辑定义在领域内部，应用服务层编排调用领域中的业务方法来实现功能点需求。
  • DDD通过定义适配器包装对外部系统的依赖,由适配器去调用外部接口，减小外部系统的变动对本系统业务逻辑的影响;

# DDD架构

# 四层架构

  • 将MVC的业务层拆分为：应用层+领域层
  • 应用层的目的是编排和组织领域行为
四层架构

# 整洁架构、洋葱圈架构

  • 模块之间为单向依赖，越往里依赖越低，代码级别越高，越是核心能力
  • 内圆需要知道外圆的任何任何情况
洋葱圈架构

# 六边形架构（端口适配器架构）

  • 核心理念是：应用是通过端口与外部进行交互的
六边形架构

# COLA架构

  • Clean Object-oriented & Layered Architecture:整洁面向对象分层架构

  • 从繁杂的业务系统中提炼出共性，找到解决业务问题的最佳共同模式，为开发人员提供统一的认知，治理混乱，帮助应用系统“从混乱到有序”

  • COLA架构不仅提供了思想，还提供了可落地的实践。由阿里巴巴出品。

# COLA架构的诞生

  • DDD架构对设计能力要求很高，没有把握好，一个错误的抽象不如不抽象。不要为了DDD而DDD，无有必要勿增实体
  • COLA里面的很多思想来自于DDD,其中包括领域包的设计

# COLA结构

  • COLA由应用架构+组件两部分构成

  • COLA中，利用依赖倒置，统一使用gateway来实现业务领域和外部领域的解耦

COLA架构1 COLA架构2

# COLA结构说明

# 适配层

  • 负责对前端展示(web、wireless,wap)的路由和适配，相当于传统MVC中的controller

# 应用层

  • 获取输入
  • 组装上下文
  • 参数校验
  • 调用领域层坐业务处理
  • 发送消息通知
  • 层次是开放的，应用层也可以直接绕过领域层，直接访问基础设施层
  • 应用层内部可通过executor+command的方式更好的解耦，exe内部通过自定义网关依赖领域层

# 领域层

  • 封装核心业务逻辑,主要包括领域服务(Domain Service)和领域对象(Domain Entiry)
  • 领域是应用的核心，不依赖任何其它层次

# 基础设施层

  • 主要负责技术细节问题的处理
  • 数据库的CRUD
  • 搜索引擎的调用
  • 文件系统的调用
  • 分布式服务的RPC等
  • 领域防腐的重任落在这里，外部依赖需要通过gateway的转义处理

# client层

  • 对操作的定义,主要包括接口和DTO
  • DTO可以细分为更新类的如Cmd 和查询类的Qry以及客户端对象CO
  • 如果需要VO，则可在此层进行定义
  • DTO与DO的转换在应用层完成.

# COLA总结

  • client模块、domain模块为根依赖
  • 应用服务层得核心任务在于编排，协调，以及事物管理
  • 领域层单向沟通应用层的方式为的交互通过event事件消息完成

# 从OOP到DDD的自我理解

  • 应用程序逐步由关注应用内部为重点，逐步转向外部;(应用逐步演进为平台，分布式应用发展、微服务理论完善与实践落地)
  • 由于程序体积的变大，导致业务复杂度上升,而业务复杂度上升又导致了分布式、微服务等；
  • 使用DDD，每个业务系统都有演变为框架的潜在可能性。(因为业务与技术分离，技术移植零成本)

← 云计算服务演进 →