作为一个java程序员，一直开发基于web的企业应用软件。技术栈是很普通的spring相关项目。原来使用的spring mvc + spring+ spring data JPA，数据库则采用开源的mysql数据库。
实践中架构的问题
1.spring mvc作为web端本质上还是java来处理前端，java作为前端处理的语言，个人觉得并不太适合。java的用类生成的对象模型来处理所有问题。但是观察前端的处理方式，php，ruby，Python，nodejs等动态语言比较流行，而且开发效率上更高。很多网站的项目原型都是基于这些语言构建的。即使运行效率不高，也可以在后期更换或者重新设计。
2.orm持久层，java的orm持久层的问题一直存在。JPA的只是一个标准，实现则基于hibernate。这种持久层映射的方式门槛很高，数据库本身的特性，也不能很好利用。如果优化之类的，也更麻烦。此类orm最大问题是为了解决对象和关系数据库的失配问题，而引入了更多的复杂性。
3.单体架构扩展能力有限
了解决上述的问题，思考可能的解决方案
前端问题：
作为后端程序员，前端是个很难解决的问题。css+html+js的方式跟单纯的编程处理问题还是有本质上的不同，要考虑展现并不是后端处理的强项。但bs的优势显而易见，即开即用的是最大优势。而且可以随时升级，无需停止服务。但是劣势也很明显，浏览器作为沙盒，面对很多限制。跟本地软件比起来，运行效率，本地调用，系统api控制等，都是它的体验落后于桌面客户端。
退一步考虑这个问题，现在html5标准有很多新特性，都是用来解决上述问题的，而且很多特性完全可以媲美本地客户端。只能说将来会更美好。
前端在提供自己的处理能力同时，也不在是简单的处理样式和简单脚本。前端也越来越向后端靠拢，nodejs的出现，使得前端的工程化更加明显。代码管理，编译，打包，发布，这些后端的开发工具渐渐也在前端形成了技术栈。
而个人认为大前端是个很好的方向，淘宝之类的大型网站都在做这些工作。它们有最优秀的前端工程师，而且这些大前端人员的业务范围不再是传统的前端，而是涉及到了后端的很大一部分操作。这是正确的方向，因为在业务上，传统的前端其实把很大的一部分责任推到了后端。因为技术的发展，它们只是承担起了自己的责任。这使得他们可以更专业的处理自己的工作。架构也更合理。
持久层问题：
个人没怎么用过hibernate，只是用过一段时间JPA。为了符合jpa的规范，把本来很好的数据库结构设计变得面目全非是常有的事。我是不明白为什么业界还在这方面努力，他们创造的问题比解决的更多。所以，mybatis的设计更合理，数据库结构的设计由业务来决定，orm只是帮助来实现数据库和代码的协作。非要把关系数据库映射成对象，简直是自寻烦扰。但是mybatis有个问题是他是基于xml的方式，xml毕竟不是java代码，java IDE的好处它一样也无法使用。
那么合理的数据库处理应该怎么样呢？
个人认为合理的方式应该是针对数据库本身的一种抽象。比如把一个表抽象成一个类，一行抽象成类对象，列抽象成字段，字段之间的关系是基于数据库关系来设计的。也就是说设计成数据库dsl的方式。用dsl来最大化控制数据库，而数据库和对象的转换，则是由程序员来控制。
最接近这种设计方式的是jooq，它的企业版收费，目前使用过程中很方便。会sql就能很好的使用这个库。
单体架构问题：
业界流行服务架构，这不仅是流行趋势，也确实是解决了单体架构的很多问题。spring 也推出了boot框架，来开发微服务的项目。只是整个项目有点庞大，涵盖方方面面。基本解决了大部分问题。
