领域驱动应对业务复杂度
领域驱动应对业务复杂度
核心业务逻辑与技术细节分离
在简单的业务场景中，系统对于扩展性的要求并不高，于是很多程序员对于扩展能力的训练就少一些。但是随着业务发展的越来越快，复杂度逐渐增高，代码中可能通过大量的if-else进行逻辑处理，在架构层面有没有好的应对扩展性的解决方案呢？
以业界流行的中台解决方案（阿里的TMF）来说，一般存在两个很重要的概念：
- 业务身份（BizCode）
- 扩展点（ExtensionPoint）
业务身份（BizCode）
指的是业务在系统中的唯一标识一个业务或者一个场景的标记。BizCode可以采用类似于Java包命名空间的方式命名，如“ali.tmall”表示的是天猫。
扩展点（ExtensionPoint）
每个业务或者场景都可以实现一个或多个扩展点。业务身份加上扩展点，可以唯一的确定一个扩展实现（Extension）。
有了业务身份和扩展点，可以从框架或者平台纬度实现多租户的管理。不同业务，不同场景都可以实现定制。阿里的中台主要也是围绕于这个思想，实现了一个平台框架的多业务支撑。
约定大于配置
最开始使用MVC架构时，听到过“约定大于配置”这句话，意思是将规则性的东西固化下来，尽量减少随心所欲而带来的复杂度。
我们可以在系统中针对于架构命名、模块命名、规范约束、组件、包等进行命名，实现标准化和约束性，以提高系统的可维护性。
网上找了一个基于DDD和CQRS的架构，通过使用扩展点和元数据提供了系统的扩展性：
总结
不管是分层架构、六边形架构，还是洋葱圈架构，还是整洁架构，我们可以发下一个共同点，就是“核心业务逻辑与技术细节分离”。我们在网关拆分上也是基于这一点做的，核心业务下沉，网关只维护技术相关细节。
核心业务逻辑下沉之后，可以实现领域模型和领域服务的复用，没有技术细节的代码也更易于RD所理解。技术细节不受业务迭代限制，随时可以升级或是丢弃。
