week 10 总结

微服务在没有微服务架构之前, 一个巨型的业务应用系统所面临的问题:编译、部署困难：功能组件多, 且依赖关系复杂, 编译耗时, 部署工作难度高; 复杂的组件依赖关系必然导致一个组件功能异常导致其他依赖方功能异常代码分支管理困难: 复用的代码模块由多个团队共同维护修改, 代码 merge 的时候难免发生冲突, 解决多个团队维护提交的代码的冲突会耗费大量的时间数据库连接耗尽: 巨型的应用、大量的访问，必然需要将这个应用部署在一个大规模的服务器集群上，应用与数据库的连接通常使用数据库连接池，以每个应用 10 个连接计算，一个数百台服务器集群的应用将需要在数据库连接上创建数千个连接，数据库服务器上，每个连接都会占用一些系统资源，以至于数据库缺乏足够的系统资源进行一般的数据操作新增业务困难：系统功能复杂, 在复杂的系统中新增功能, 难度大解决上述困难的方案就是对系统进行拆分，将系统按照模块分解，将模块独立部署，降低系统耦合性，系统拆分的方法有：纵向拆分：将一个大应用拆分为多个小应用，如果新增业务比较独立，那么就直接将其设计部署为一个独立的系统横向拆分：将复杂的业务拆分出来，独立部署为微服务，新增业务只需要调用这些微服务即可快速搭建一个应用系统



领域驱动设计：贫血模型 VS 充血模型

领域是一个组织所做的事情以及其包含的一切，通俗的说，就是组织的业务范围和做事方式，也是软件开发的目标范围。领域驱动就是从领域出发，分析领域内模型及其关系，进而设计软件系统的方法。子域：通常一个领域拆分成多个子域限界上下文：在一个子域中，会创建一个概念上的领域边界，在这个边界中，任何领域对象都只表示特定于该边界内部的确切含义，这样的边界便称为限界上下文上下文映射图：不同的限界上下文，也就是不同的子系统或者模块之间会有各种的交互合作。DDD使用上下文映射图来设计这种交互。实体：领域模型对象。每个实体都是唯一的，具有一个唯一标识值对象：值对象是不变的，没有行为和状态，仅仅用来作为度量或描述的对象。聚合：关联对象的集合聚合根：将多个实体和值对象聚合在一起的实体



DDD分层架构：用户接口层、应用层、领域层领域实体的组合调用和事务控制在应用层DDD六边形架构DDD战略设计与战术设计战略设计：领域、子域、限界上下文、上下文映射图、战术设计：实体、值对象、聚合、CQRS、时间溯源通过战略设计，划分模块和服务的边界及依赖关系