站在EOS平臺用戶的角度，不客氣的說，Eclipse中EOS的應用在國內是領先的，也有朋友通過學習EOS的設計和原理，在工作中獲得了很大的幫助。
所以在我看來，使用任何工具和平臺能否獲得個人的技術成長，取決於妳能否從平臺的使用中得到提升和總結，不是把平臺當工具，而是把平臺當教材。想想如何設計壹個平臺，如何構建壹個層級體系等等。
在技術路線上，企業平臺是最接近最新技術的，普元就是其中之壹。普元正在升級EOS微服務框架和容器雲，並將其在BPS方面的優勢應用於DevOps的設計和實現。
而且，普元正在開發新壹代數字化企業雲平臺，目標是發布壹個可以部署在私有和公共環境的Paas平臺。有興趣或者想學習相關技術，可以在百度搜索EAII。
附上EOS設計師智虎的壹段回答。供參考。
作者:焦烈艷
鏈接:公司將引入普元公司的EOS框架，對公司未來的技術發展有什麽影響？——焦烈焰的回答
來源:知乎。
版權歸作者所有，授權請聯系作者。
今天剛看到這個問題。作為EOS的設計師，我不敢客觀的說，主要說說設計時的思考。
1的初衷。EOS是為了解決企業JAVA開發中的壹些* * *問題。雖然有很多框架比如SSH，但是有很多非功能性的需求在應用過程中沒有涉及到，尤其是在分布式環境下，以hibernate為例，如何實現多服務器配置文件的同步，如何在集群狀態下監控性能，這些都不是開源軟件能夠解決的。因為我們有很多大客戶的經驗，比如華為工行，所以我們在產品中體現了很多類似的經驗。EOS並沒有解決業務邏輯快速開發的問題，而是解決了企業環境中非功能性需求的問題，提高了軟件的可管理性，尤其是大型軟件開發，這也和我們的經驗有關。我同意何的觀點，目前市場上的快速開發平臺是不可能解決復雜ERP系統的快速開發的。所以在設計之初，EOS考慮的是解決非功能性需求的實現，而不是業務邏輯的快速開發。
2.基於JAVA做應用架構有很多方法，這也是為什麽有很多開源軟件的原因。不同的人有不同的看法。既然EOS試圖解決JAVA的應用架構，那麽必然有自己的想法。這些想法可能不會得到所有人的認同。這也是我過去比較頭疼的問題，也是開發者比較有爭議的問題。不像工作流，大家對它都有清晰的認識和定位，比拼的是功能和性能。普元的工作流性能很強，對外接口功能特別豐富(真的不是吹牛)，所以獲得了很多認可。
3.EOS最有爭議的是業務邏輯的拖拽開發(也就是可視化開發)。其實大家都不反對拖拽式開發，比如數據建模，但是拖拽業務邏輯未必是好事。我們在設計的時候，要麽用拖拽開發，要麽用spring bean的方式寫代碼開發業務邏輯。圖形化(拖放)開發業務邏輯，最大的用途是處理異步邏輯，比如調用WebServices。如果同步調用時被調用者很慢，當前線程會被掛起，那麽異步就不會有這個問題，至少可以隨時間釋放(這裏比較復雜，我就不贅述了)，但是異步代碼寫起來很復雜，如果回調的話很難讀取(想象壹下回調調用三個網頁)
4.在使用EOS的時候，最好根據自己的情況制定規範，因為EOS在做產品的過程中要考慮很多情況，但是企業面臨的問題是固定的。比如妳不喜歡拖拽業務邏輯，妳可以不用，因為妳在普元的培訓裏講過這個方法，妳也可以和普元的工程師討論。技術團隊在使用壹個框架時，可以從設計原理、架構、面臨的問題等角度考慮框架的設計初衷，從而提高對技術的掌握。我的很多合作夥伴(比如工行、建行)對EOS的掌握很深，並結合自己的實際成為自己的框架，他們的技術也在這個過程中得到了很大的提升。
作為設計師，EOS是壹個在設計過程中困擾我們的產品。主要原因是他試圖解決的問題復雜而廣泛，解決這個問題的方法有很多，尤其是開源軟件很多，不可能面面俱到。在濮院後續產品的設計中，我們吸取了這壹經驗，重點解決了需要解決的問題。
6.未來，普元將解決大中型企業信息化的技術架構問題，但設計思路會更加專註。在EOS和process之後，還有ESB、數據集成、數據質量、IaaS等產品。目前的數據集成產品都是基於最流行的開源軟件Kettle，但是我們的重點是解決Kettle沒有解決的調度問題(比如每天晚上有幾千個作業，可能會連續持續，作業失敗怎麽辦，如何監控等等。);目前IaaS產品都是基於OpenStack的，但是我們已經解決了OpenStack在企業私有雲的管理系統問題(比如小網段、心跳檢測、高可用以及高可用組件本身的多維度管理)。數據治理產品側重於數據整合後的數據譜系分析和影響力分析，形成數據圖譜。