下面的11-13章内容是战略模式中在有界上下文之间通信,有界上下文表示的是业务能力
1.如何集成有界上下文
如何集成有界上下文，就是说如何把已经识别出的上下文做项目实施、做编码方案、通信方案。有界上下文尽量是松耦合的，可以让不同团队独立开发，降低相互依赖。
- 代码层面集成有界上下文
有界上下文代表了具体的业务能力，如果不同的业务能力放在同一个代码仓库中，比如运输和销售，如果添加运输相关的功能时在销售模块也增加代码，就无法起到隔离作用了，所以要依据单一职责模式的约定让每个模块独立，避免耦合。（这里的耦合不是说完全不能相互调用，应该是底层的方法不应该相互依赖，但是模块之间只依赖最上层的接口并且是单向依赖就像微服务那样也是可以的，毕竟有界上下文之间也是有调用关系的），不一定非要在同一个代码仓库，因为有的时候不同的上下文编程语言可能都不一样，自然没有办法在一个代码仓库，在同一个代码仓库上下文要做好隔离，编程语言有隔离机制比如命名空间、包名，不同上下文的即使存在相似代码也应该在每个模块单独实现，因为随着时间推移不同上下文代码差异会增加，但是也有以下缺点，所以一般采用的物理隔离实实现上下文隔离。
- 多个团队共用一个代码仓库开发效率会降低
- 因为很多需求可能是并行的，导致代码频繁冲突，需要耗费大量精力解决。
- 因为所有代码都在一块，如果代码设计不合理很容易导致耦合、开发人员学习成本比较高。
- 代码发布时QA回归的成本高，需要回归所有的case才能保证上线无影响。
- 资源容易成为瓶颈
- 资源容易成为瓶颈。比如一个数据库性能是有限的，随着业务增加对数据库访问要求会提高，逐渐不能满足业务。
- 难以做到服务降级、故障隔离。比如共用一个数据库，导致任意一个业务对数据库资源占用过多，都会导致其他资源不可用。
- 无法更加合理的水平扩容。如果我们是微服务架构，可以针对不同的服务的业务访问压力，合理配置部署节点数量实现提高系统的吞吐量，单体架构只能按照系统访问要求最高的业务来扩展。
-
使用物理边界强制实现模型整洁
这个就是常见的微服务，每个上下文当成一个微服务，有独立的代码仓库、
开发人员、数据库和其他的资源。 -
历史遗留的系统的集成
可以通过不直接调用遗留系统接口，在上面增加一个防止损坏层，然后慢慢
的在防止损坏层下实现新的上下文慢慢替代旧的服务。但是如果调用旧系统
的服务非常多，每个调用方需要的格式都不一样，可以将防止损坏层放在被
调用方，旧的服务只是公开自己旧的API，被调用方自己在防腐层做转换，当
以后有新的服务时，被调用方重新实现防腐层的转换逻辑，内部业务代码就可以不用变化。
2. 集成分布式有界上下文
- 集成分布式有界上下文的策略
微服务分布式是非常流行的方案，分布式将可用性、可靠性、扩展性摆上了
台面，分布式之间通信可以用RPC或异步消息。但是如果系统如果对可扩展
性有非常高要求，前期可以采用数据库集成，比如两个订单和结算系统共用一个数据库，订单数据写入，结算上下文去扫表去完成业务需求，但是这个目前看极其不推荐，应该没有这么设计系统的，除非项目前期精力 极其有限，以后也是要改的。
-
DDD使用分布式的挑战
-
RPC通信依赖网络有CAP问题，幂等、超时、重试、节点故障等等。
-
扩展RPC代价更高，比如为了支持更多并发访问量，每个服务可能都需要进行扩展资源。
-
RPC耦合（这个是难以避免的）
逻辑耦合：比如创建订单过程必须调用商品、优惠中心、计价、购物车、交易系统才能完成。
临时耦合：这个是说在一个完整的调用链路里面，中间一个环节增加业务处理逻辑导致耗时增加，会对性能产生影响。 -
分布式事务损坏可靠性和可扩展性
案例：预定由酒店和航班组成的假期，酒店信息存在自己系统，航班存在外部系统，过程可能持续几秒钟。每次都提前锁定数据库里面的酒店数据，在调用航班系统。
-
数据库的连接和锁持续增加，过一段时间就会拒绝服务。
-
航班系统可能出现故障了，这个时候要解锁。因为酒店和航班需要同时预定这个业务，导致中间酒店无法被人预定，这也导致了系统受益减少，因为很多人可能就仅仅需要预定酒店。
有界上下文不必保持一致，把锁数据库数据的操作换成一个特定状态，比如预定中，航班预定失败要回滚状态，但是这个回滚可以是用异步消息处理的，所以一般会选择最终一致性，在适合的业务场景下可以用异步消息替代RPC调用。
-
-
-
微服务和有界上下文
一个微服务可以不止有一个有界上下文，因为有的拆分微服务的数量太多的话维护成本很高，另外两个有界上下文依赖非常密切，单独拆分成微服务会增加RPC调用增加通信成本。比如购物车、计价可以集成在一个微服务里面。另一个是有些上下文目前逻辑非常简单，甚至就是在另一个服务的基础上随着业务独立出来的一个模块，当前来说可能没有必要拆分，这个时候可以可以部署在一个微服务项目下，按照DDD的代码设计，这两个有界上下文分别是两个domain，当domain越来越重的时候，完全很好的拆分成为独立的服务，这个在战术设计代码层面会提及。
结论：本章讲了有界上下文的集成方式，有界上下文表示的是业务能力，要选择适合自己的，可以选择代码层面通过模块化集成、数据库集成、拆分微服务，但是业务都是慢慢发展起来的，刚开始一般都是单体应用，不会一上来就上微服务的，但是我们了解这些以后可以提前做规划，比如在代码层面设计的好一些，方便以后更加容易拆分，通用代码层面也不一定非要按照DDD的架构设计，但是至少要实现按照有界上下文隔离、确定调用关系，了解这些前瞻性的见解对项目发展是有好处的。
网友评论