有一个Java Web的系统，原来只是一个普通的Spring MVC项目。但是因为后期会有多个迭代，在二期的时候，设计者考虑用CQRS来组织项目。但有一个问题设计者当时没考虑到，直接新开一个库地址进行开发，认为一个前端不同页面对应两个后台很容易。然而事实证明，这会存在跨域访问的问题。处理办法就是需要在服务端的HTTP相应数据头中写入Access-Control-Allow-Origin字段。比较好且不造轮子的方案就是升级Spring版本到任意一个能够使用@CrossOrigin注解的版本。配置CORS（跨域资源共享）Filter。
然而这样虽然可以保证两台机器直连，但是由于线上环境比较复杂，中间会有诸如验证之类的第三方服务。因此最终的解决方案是做gateway转发请求。从某种意义上来说，一个完整的项目被割裂了，而且还不完全互相独立。只能后期将原先代码重构到现有的CQRS架构上。
再谈谈关于代码，实现一个分层应用代价是很高的。在很多场景程序员为了快速开发，都是直接一个持久层对象裸奔到最上层的。一个良好的分层架构软件，至少得要区分请求数据，一般也就是DTO的形式，内部对象是否就一种形式直接裸奔到持久层，不必过于教条。现有的系统升级是有领域对象的，然而一个比较严重的问题是程序员对业务背景的匮乏，导致系统中领域对象非常贫血且与持久层对象高度雷同，这就导致了不少的重复代码，与大量的属性赋值语句。这种代码明显是违背了软件设计中的开放封闭原则，任何一个小小的字段变化，无论是增加、删除还是改个名字都会引发霰弹式修改。现在来说，也是比较无奈，因为现在还没有人非常清楚最终系统要做成什么样。开发、维护成本高归根到底还是缺少一个DDD（领域驱动设计）中的所谓领域专家。