Part6 – (1) 软件架构设计的怪现状
架构设计之怪现状：
1、“迷信大公司”。
2、“迷信流行技术”。坑老板指南。
3、应该怎么做？结合公司，结合项目，选择最适合自己的。
架构是进化而来的：
1、淘宝的进化故事。几个开发人员，用买来的拍卖程序三个月改出来的。
2、很多项目第一天就是奔着淘宝去的，然后。。。
3、“最小的可行性产品”MVP；“演进式架构“；
4、避免软件退化以及如何预防。
Part6 – (2) 什么是微服务
单体结构项目：
缺点：
- 耦合；
- 技术栈统一，软件包版本锁定；
- 一崩全崩；
- 升级周期长；
- 无法局部扩容；
微服务结构项目：
- 优点：耦合性低，易于开发和维护；可以用不同技术栈；可以单独扩容；互相隔离，影响小；部署周期短；
- 缺点：对运维能力要求高；运行效率会降低；技术要求高，需要处理事务最终一致性等问题。
微服务的误区：
微服务架构应该是进化而来的；微服务的拆分进化。
Part6 – (3) 什么是DDD, 应该怎么学？
什么是DDD?
1、DDD（Domain-driven design，领域驱动设计）是一个很好的应用于微服务架构的方法论。
2、在项目的全生命周期内，所有岗位的人员都基于对业务的相同的理解来开展工作。所有人员站在用户的角度、业务的角度去思考问题，而不是站在技术的角度去思考问题。
3、诞生于2004年，兴起于2014年（微服务元年）。
DDD之难
1、DDD晦涩难懂，难以落地。因为DDD是方法论，不是行动指南。
2、“盐少许、油少许“，每个人对DDD的理解和落地都不同，而且没有绝对的对错。
3、如果只学习DDD概念而没有了解如何应用的话，会感觉没有落地；而如果过早关注落地的话，会导致理解片面。
DDD学习之道
1、正确姿势：“从理论到实践，从实践再到理论……”
- 顺序：把概念的讲解和技术落地分开。Why？
2、不要一下子学DDD的整体。不同岗位、不同阶段的人先从自己的角度学习DDD的一部分。
Part6 – (4) DDD之领域模型与事物脚本
领域：
1、“领域”（Domain）：一个组织做的事情。子领域。
2、领域的划分（以手机公司为例）：
- 核心域：解决项目的核心问题，和组织业务紧密相关。
- 支撑域：解决项目的非核心问题，则具有组织特性，但不具有通用性。
- 通用域：解决通用问题，没有组织特性。
手机公司，子领域：手机设计子领域，手机制造子领域，软件App设计子领域，销售子领域，市场子领域，售后子领域，后勤子领域，人事子领域；
3、领域的不同分类决定了公司的研发重点。
领域模型（Domain Model）
1、对于领域内的对象进行建模，从而抽象出来模型。以银行为例。银行网点系统子领域：柜员 客户 ATM 排队机。
2、我们的项目应该开始于创建领域模型，而不是考虑如何设计数据库和编写代码。使用领域模型，我们可以一直用业务语言去描述和构建系统，而不是使用技术人员的语言。
尽可能早设计，晚实现。
事务脚本（X）
使用技术人员的语言去描述和实现业务事务。没有太多设计，没有考虑可扩展性、可维护性，流水账地编写代码。
事务脚本的问题：代码的可维护性、可扩展性非常差。比如如何增加“取款金额大于5万元需要主管审批”、“通知短信”等功能。
Part6 – (5) DDD之通用语言和界限上下文
通用语言
1、“我想要商品可以被删除”→“我想要把删除的还原回来”→“Windows回收站都能”
2、此“用户”非彼“用户”。
3、通用语言：一个拥有确切含义的、没有二义性的语言。
id Delete from t where id=? 软删除-隐藏
界限上下文
通用语言离不开特定的语义环境，只有确定了通用语言所在的边界，才能没有歧义的描述一个业务对象。
- windows文件系统：删除
- 用户：后台管理系统：用户管理员
- 商城购物车：用户 买家
本文版权归个人技术分享站点所有，发布者：chaoqiang，转转请注明出处：https://www.zhengchaoqiang.com/1553.html
