微服务下的领域框架对管理者有何意义

刀耕火种的开发困境

最开始做开发，只追求拿来主义，能用就行（对新手而言，复杂点的设计下可能代码都跑不起来了。。）。对于Spring 生态及其衍生物，只求能用，最开始的项目，是一个Spring Boot项目，根据项目需求，往里加依赖，然后单体项目微服务化，照葫芦画瓢。

项目大了之后，“我”变多了，大家都往项目中塞依赖，塞逻辑，终于有一天，业务逻辑开发效率断崖式下降，维护成本断崖式上升，例如：

• 某类接口被检查出漏洞，需要根据用户角色做权限限制，但用户、角色信息分散在不同模型，修复成本高；
• 某模块开发过程发现缺失一些信息，这些信息在另一个模块，还要根据两个模块的打通做设计；
• 两个模块联动查询用户信息，在用户列表查询时有太多跨模块请求，页面性能很差；

那就加班吧，大家攻坚一轮，或者又有反馈：新的方案不太行了，有部分数据要联合第三个模块联动，还要重新设计。

终于有一天，问题在高强度加班中暂时解决了，痛定思痛，管理者要求大家在做开发前要先做设计。然后大家就开始设计，但设计的过程总有敷衍的情况，有的是个别流程图，有的是数据库表设计，不能对开发中的重点难点做有效指导，大家反馈：

• 程序员写文档并不在行；
• 很难在开发前直接做出完美的设计方案；
• 行动主义的开发人员认为先动手干活才是硬道理；

果不其然，有一天，又爆出阻塞开发进度的问题，大家又风风火火拉会议讨论怎么解决。

领域建模的引入

“微服务架构要用DDD！”这个声音传到了团队里，刀耕火种的时代要过去了。

通过将领域有效划分，不同实体存在于不同领域、上下文中，建立一套领域间的通信机制，有一套开发方法论开始指导开发，有以下价值：

1. 产品经理不再发散设计。缺少领域建模，产品经理仅有的设计指导方法论是和业务契合度、提高用户体验有关的。这样做的问题是实现成本可能远高于业务价值，产品经理在领域建模思想下梳理事件，划分领域，开始收敛设计边界，砍到多余或不合理设计；
2. 产品经理和开发建立共同语言。有时候开发提出某某功能点改动大，产品经理也很被动，因为产品经理不一定懂开发，最后方案可能根据可实现性改得七零八落。基于领域建模，项目组不同岗位之间建立了一套共同认可，看得懂的领域模型，模型如设计合理，既能满足业务需求，也具备落地可行性；
3. 提高系统性能。由于开发也基于领域建模思考设计，不同实体的重复建设、实体间繁杂的低效率通信、领域服务的调用链过长等问题在设计过程汇总得到有效控制，最终可以提高系统性能。而系统性能提升的本质是设计的合理性，同样带来系统健壮、开发成本可控、维护成本可控的优势；

领域框架的引入

领域建模是一套思想，最终需要一套开发框架落地。领域框架进一步提供了：

1. 整体项目脚手架。提供一揽子项目基础结构，让领域建模可规范落地；
2. 基建设施的提供。领域建模的基础层提供，包括数据访问能力、缓存、队列等，解放业务逻辑解耦无关技术实现；
3. 业务层和领域层的通信规范。规范定义了请求和执行命令、返回的数据结构、各领域服务的表现形式；

在领域框架下开发，遵循规范可以可控地完成原领域建模的开发工作，难点在于开发中后期发现原领域建模需优化的地方，此时产品设计和技术实现可能发散，从而使领域建模开始臃肿、不合理。这是最考验领域建模实践的时候，产品和开发要保持克制，基于原领域建模完成必要的优化，规范地修改代码，这最后一公里路决定了领域建模落地的最终成型。