架构设计与方法论
2021-04-16 10:46:39 0 举报AI智能生成
架构设计与方法论
作者其他创作
大纲/内容
SOLID
S-单一职责
职责单一，被修改的理由就少
O-开闭原则
重载，多态
L-里氏替换
子类应该可以完美替换父类
I-接口隔离
分拆接口，专门的功能在专门的接口中定义，类要避免实现不必要的接口方法
D-依赖倒置
DDD
领域模型定义
之前所有业务都在service层，各业务实体对应的bean仅有getters, setters,称为贫血模式
DDD倡导第个领域模型应实现与其相关的业务逻辑。。如“银行帐号”实体应实现“借出”、“贷款”等基本业务逻辑
Service层只是负责宏观的业务组装，而不应该关注与领域模型相关的细节
其中用到了策略模式。不同类型实体的同一类实现，应定义在各自实体中
以上的理论遵循的是solid单一职责S
驱动模型
传统的数据驱动
需求分析-》数据建模-》建库建表建DAO-》编写数据操作逻辑
领域驱动DDD
需求分析-》领域分析-》领域建模-》核心业务逻辑-》技术细节
语言
传统的数据驱动
用户语言（业务语言）需要转换为数据驱动的模型语言，体现至代码层面。业务和技术存在沟通上的障碍
领域驱动DDD
从用户到产品到技术，都采用统一的沟通术语，用户对于真实事物的操作的理解，是完整的映射到代码层面的，因此统一语言得一确立
面向对象
DDD更关注于面向对象，所有的核心业务都与对象关联。对象在技术层面再也不是面向数据驱动时的数据库表的映射。
逻辑解耦
核心逻辑
核心业务逻辑应该在领域模型中
周边技术细节
数据层
不应与核心逻辑强绑定，应该分离出来，数据的保存方式，技术类型可以是不固定的
技术框架
核心逻辑在各种技术框架中都应该行得通，两者职责不同，应该是松耦合关系
相对于hibernate对于项目结构的强侵入模式（映射对象参与业务组装），mybatis应该更受欢迎
核心思想：业务逻辑不应该依赖于技术框架
域
核心子领域
核心逻辑
通用子领域
所有领域公用，通用性很强，可从第三方购入
日志记录、操作记录、权限认证
支撑子领域
非核心逻辑，通用性不强，有企业特点
隔离内核
非核心域的功能，划分至其他模块
限界上下文
模块划分的参照，微服务划分的参照
微服务知识框架
RESTful、RPC
什么是接口契约IDL
消息协议
组件、框架
基本框架
DDD分层架构
用户界面层
应用层
对外接口提供，定义业务，操作领域方法并组装数据
领域层
具体的业务实现方法
基础设施层
业务最终的数据实现
洋葱架构
六边形架构
全方位监控
日志
应用内安装Agent上传日志
FileBeat
消息缓冲
Kafka
日志收集搜索
ELK
Metrics
InfluxDB
grafana
健康检测
nagios
调用链
CAT
Kinpin
Pinpoint
告警
容器化
微服务边界
数据库不与其他微服务分享
微服务治理
分布式配置中心
文档
统一异常处理
日志级别
编码code规约
Exception分层定义
底层通讯http/tcp
序列化、XML、JSON、二进制
协议规范：RESTful、RPC
安全、访问控制
SSRF
容错：限流熔断降级
调用链监控
Metrics分析
日志
负载均衡
服务注册发现
UML
设计产出
概要设计
功能模块划分
系统与子系统
子系统间通讯方式
外部系统依赖
对外部系统的影响
技术路线选择
UI、存储层（如果涉及到）
详细设计
安全性
https
XSS
CSRF
哈希洪水攻击
拖库，洗库，撞库
密码安全规范
爬虫
跨站脚本
拒绝服务
审计安全
热度技术补充
（具体问解决方案）
（具体问解决方案）
容灾
双活架构
容错
过载保护
APM监控
分布式任务调度
流式计算
单点登录
容量规划
0 条评论
下一页
