作為一個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框架，來開發微服務的項目。只是整個項目有點龐大，涵蓋方方面面。基本解決了大部分問題。