摩爾78
題主的問題很有代表性，尤其是對企業信息化建設前期進行技術選型時，需要重點考慮。根據本人經驗，通過Java開發平臺做平臺開發時，建議關注以下幾個方面：
第一、統籌開發目標，關注系統架構設計，
如果你的目標是建設一個平臺，那就說明不是一個小項目，一定要明確開發目標（尤其是階段性里程碑目標）。在項目整體目標明確後，做好系統架構設計。系統架構設計不聚焦在Java開發平臺上，而是界定好平臺內部各個功能模塊（或業務組件）之間的關係，確定通信機制和訪問協議。如果是計劃建設的平臺規模較大（如：將來計劃用戶量上千萬，或後臺數據TB級別），可能還需要做好中臺建設（關於中臺的建設此處不再展開），但一個信息化平臺至少包含以下幾個部分：
- 權限體系
- 安全體系
- 數據訪問體系
- 接口通信體系
- 基礎功能體系
- 業務功能體系
- 用戶交互體系
▲通用系統架構
第二、儘量做到功能解耦，強化系統可擴展性
Java開發一大優點是可實現跨平臺運行，無論是Windows服務器還是Linux服務器，只需要安裝JVM和JDK即可，從而實現了開發程序和操作系統的解耦。但平臺建設最難的是業務功能的解耦。幾乎所有平臺都會涉及到安全體系、權限體系、跨域訪問等問題。在平臺架構設計完善後，務必要將業務功能解耦，將公共調用的功能模塊抽象出來，形成獨立的組件，尤其是涉及到後臺算法和性能的組件，更需要從具體業務模塊中抽象出來。在組件調用時形成固定通用的調用接口，可以使封裝後調用，也可以是代碼級、工程級引用。這樣既可做到平臺業務可擴展，也增強了後續升級迭代的便捷性。
▲功能解耦示意圖
第三、用成熟的第三方組件，強調代碼可維護性
Java另一特點是其龐大的開源體系，可以從GitHub上獲得巨量支持。通常我們可以引入第三方成熟的組件，以快速高效實現特定系統功能的效果。但引入第三方組件時，最好遵循開源和成熟的原則。以便在業務調整，需要修改組件涉及到的相關功能時，可直接修改組件相關源碼。
另外，Java開發時養成良好的編碼習慣，增強代碼可維護性也非常必要。尤其是平臺核心代碼，最好做好註解解釋，並對版本進行控制，以便升級迭代操作。
▲Spring框架的核心代碼示例
希望以上三點能幫到您！
IT駱駝
湘北智造XJR是一款不錯的可視化快速開發平臺，操作非常簡單，可以不用美工，前端，資深開發工程師，能在短時間內完成各類專業性強的工作。短期內輕鬆開發出如ERP、CRM、WMS、MIS、OA等各類管理系統。極大地節約了開發/維護的成本和週期。
XJR快速開發平臺大部分功能通過拖拽設置即可設計出業務功能、流程、報表、app、小程序等應用，並自動生成源代碼，極大地節約了開發/維護的成本和週期。
平臺特點
兼容性
支持JAVA/.NETCORE兩種類型支持多種類型數據庫
面向服務/接口設計，可輕鬆集成或集成到外部系統，輕鬆整合企業現有資源
插件式開發，基於該平臺
開發出來的業務功能可以直接插入到該平臺的其它項目
易用性
可視化開發表單、報表、小程序、APP、審批流等業務，降低開發難度。
對開發人員要求低，您只要有編程理念有一定的SQL基礎， 甚至沒有JAVA、.NET、前端開發經驗的程序員也可以完成項目開發。
一個程序員可以完成從架構師、 後端程序員、前端程序員的所有工作、堪稱化弱雞為全棧。
功能性
前後端分離，共享服務總線
開放應用項目源代碼，可擴展性強，原則上所有複雜業務皆可實現。
開發效率高，曾有一實習生程序員1天做20多個單表業務功能的記錄
細粒度的權限管控，通過簡單配置就可以實現功能權限和數據權限
服務性
提供優質的售後服務，有專業的售後專家為您解答開發難題
提供入門視頻，觀看一小時即可動手開發項目，無懼開發組人員流失
板栗子13117930
其實關鍵是前端，這幾年流行前後端分離，java技術棧已經收縮成了服務層 持久層和集成層，表現層已經讓給百花齊放的前端框架和工具。
這也許是一種進步 一種趨勢，但是這造成了開發成本飆升。
開發一個大型後臺管理系統，應該選擇前後端分離的技術方案嗎？
目前在前端領域 angular react vue絕對是三大當紅花旦，但是也讓無數碼農陷入選擇困難症，引發了大量無休無止的爭論。很多討論 當事人已經忘記了討論的初衷和邊界，最後陷入無意義的口水戰。
一、結合“開發一個大型後臺管理系統”這個約束條件 冷靜的分析一下該怎麼選：
什麼是後臺管理系統：後臺管理系統 這個稱呼 意味著這是一個B端系統，可以小到部門級應用（客戶投訴登記系統、辦公設備臺賬系統），大一點可以是大集團級核心系統（500強保險公司客服、呼叫中心），可以是ERP、CRM、OA產品（SAP、用友、泛微協同），可以是一個B2C電商的商城後臺、支付網關管理控制檯，可以是Saas的管理後臺（Salesforce、Teambition、Jira），可以大到阿里雲控制檯。。。
什麼是大型：我理解大型系統是指功能模塊多、交互複雜，而不是訪問量、TPS、數據量大；所以CMS、OA、ERP、CRM、阿里雲後臺、呼叫中心、各種管理系統 只要功能多都可以稱為大型系統，雖然他們體量和交易量可能不在一個量級。 另外大型系統基本等價於“維護週期長 需求不斷變更”，這個在後面維護成本部分闡述。
性能考量不是主要決定因素：因為我們這裡討論的是B端系統的前端技術選型，因此我的觀點是性能不是主要考慮因素，因為性能瓶頸往往在後端和數據庫，其次B端產品不存在爆發性交易量（秒殺 大促 活動），最後B端產品不強調首屏渲染速度。
UI操作效率是最主要考核指標：B端系統產品都是用來幹活兒、管理、生產調度的，操作效率和方便性大於天。屏幕空間要充分利用 減少切換跳轉彈窗；快捷鍵效率遠高於鼠標；SPA 多頁籤佈局有利於保持工作上下文和狀態；必要時可以鼠標右鍵菜單操作；功能菜單操作提示要清晰易理解 減少培訓麻煩；在此基礎上 儘量少每一個界面上呈現的信息量 只呈現最少的必要信息 降低用戶認知壓力；
UI開發效率高維護成本低是關鍵考量因素：大型系統基本等價於“維護週期長 需求不斷變更”，因此在技術選型上必須要求維護成本低、學習成本低、招聘容易、組件化程度高代碼簡潔。。。
UI顏值美觀度不是關鍵考量方面：界面簡潔大方 圖表豐富 數據展現清晰，這其實本身就是一種美——樸素實用的美。
瀏覽器兼容性 看情況：Saas要求兼容性高，內網系統內部系統可以強制統一瀏覽器。
二、前後端分離對於“大型後臺管理系統”弊遠遠大於利
大型後臺管理系統 其實還隱含等價於“業務邏輯複雜”！相對於C端產品，B端產品業務邏輯複雜得多。我不是說B一定比C難做，C有另外的難度（比如用戶體驗、比如競品之間的競爭更加激烈、比如併發量挑戰、比如做活動的需求頻繁。。。）。單說產品核心業務邏輯，B一定是更高的。
複雜業務邏輯的產品 一定不是單靠產品經理、BA或前端設計出來的，也不是不能做，但那樣的產品 在業務抽象度、擴展性、實用性方面容易往往存在先天不足（無意引起爭論 一家之言）。
解決的辦法其實很簡單：產品、美工、開發各工種人員密切配合 快速原型 MVP（Minimum Viable Product） 快速迭代 快速試錯，
全棧開發的效率 效果 要遠遠高於前後端分離；
這裡說的“效果”指的是趁熱打鐵和技術主觀能動性的效果。
那種“產品畫框圖 美工做設計稿 前端切圖 扔給程序員渲染模板”的傳統開發流水線，會徹底拖慢一個業務需求從想法到交付的週期 會徹底割裂整個團隊 會遺漏大量的上下文信息 會增加巨大溝通成本 會徹底磨滅項目成員的參與感和對產品的歸屬感。
畫圖仔、切圖仔和碼農 按部就班像流水線擰螺絲一樣開發產品，絕對無法創建出一個有靈魂有靈性的產品！
更不用提前後端分離造成的開發、聯調、部署、定接口、維護接口的成本提高。
另外前後端分離也不適合項目型公司，因為項目週期有限 分離的團隊組建起來 磨合順暢就很耗時，項目結束後又解散，下個項目重複資源浪費。留守項目的人員配置不齊 導致需求變更和維護問題難以解決。
綜上：angular react vue基本意味著前後端分離的開發和部署模式，這已經在根本上決定了它們不適合“大型後臺管理系統”，原因 一方面是上面列舉的種種弊端，另一方面是大型後臺管理系統無法享受到前後端分離的好處：nginx分開部署的優勢、專業前端優勢（C端產品追求極致的顏值和用戶體驗）。
既然這麼多弊端 又享受不到優勢，為什麼很多企業（項目）跟風搞前後端分離 跟風上vue react呢？ 答案其實很無奈“簡歷驅動的開發”、“KPI驅動的技術選型”。
三、切忌“簡歷驅動的開發”、“KPI驅動的技術選型”
軟件開發絕對是個良心活兒，跟醫生 教師。。。一樣的。
我這幾年見到了太多的微型團隊（10人以下）搞微服務架構，百萬級數據量的大數據項目，以及前後端分離的CMS內容管理系統！
見了太多為了用時髦技術而盲目選型的事情，太多不計後果不計成本的追求新技術來美化自己簡歷，太多用流行技術名詞忽悠自己不懂技術的老闆 上司的情況。
你們的良心不會痛嗎？
當你在簡歷上加上了一個個流行技術關鍵詞，然後拍拍屁股離開了一個爛尾的項目 一個預算嚴重超支的項目 讓創業團隊多走幾年彎路甚至夭折，你的良心和職業素養都破產了！
你正在透支技術人這個工種這個群體的社會聲譽。
技術人的天職 本應是把複雜模糊的現實世界問題 建模成清晰邏輯結構化的計算機軟硬件，讓世界變得更簡單高效，如果因為一些奇怪的原因而把簡單問題複雜化，那就是背離了這個行業的初衷。
希望越來越多的甲方、非技術出身的高管們明白一個道理：靠譜的人是把解決方案做的很簡單以至於明顯沒有問題，不靠譜的人會把解決方案做的毫無必要的複雜以至於短時間內看不出明顯的問題。
前後端分離不是壞的，跟風才是壞的
前後端分離的出現和存在，當然有它的合理性和優勢，看看誰創造了它們——谷歌的angular、facebook的react、阿里的antd、餓了麼的element、前谷歌程序員尤雨溪創建的vue。
總之就是IT大廠在創造和使用這些技術，這個我就不展開討論了，超出了我的能力範圍。
但是簡單看下它們創建產生的背景 當時的初衷 後來的成功案例，不難發現 這裡面其實還沒有erp crm這種典型的B端大型複雜系統。
所以我建議 至少不要不加思索的就把前端選型的候選人圈定在這三個當紅花旦，不要覺得跟著互聯網大廠走就一定不會錯。
彼之良藥汝之砒霜，你要搞清楚你自己是什麼樣的定位！
互聯網大廠 獨角獸 前沿風口上的明星產品很多情況下都是資本遊戲 燒著風投的錢 靠補貼做活動 砸廣告費引流做出來的數據 把估值做高找下一輪風投接盤。如果你是這種情況 那沒的說，儘管選最好最貴對標一線大廠技術棧 甚至人都是各大廠挖來的。
如果你們是做項目賺辛苦錢 或自己投資研發產品，在傳統方向在產業互聯網精耕細作 慢慢摸索培育市場 不在風口不受風投追捧的，那我覺得你們需要務實一些。
我建議各位本著務實和誠實的態度、職業精神操守，結合自己公司 團隊 項目 業務需求，選擇最適合自己的技術棧。
問題還是回到“開發一個大型後臺管理系統，應該選擇前後端分離的技術方案嗎”？
我對java開發為主的公司和團隊 推薦一個東西：ZK（The leading enterprise Ajax framework） 純java的企業級前端框架。
https://blog.csdn.net/daquan198163/article/details/9304897 https://www.zkoss.org/
自信中國人上海程序員
Github上有很多這樣的腳手架工程，如果是java類的，最多的是spring boot+mybatis+mysql了，如果需要權限管理，目前來說spring security已經要好於shiro了，如果你的項目比較大，語言搜索類的，可以使用elasticsearch一些github上都有現成的開源代碼
再說前臺，如果想快速集成的話，可以使用vue,框架可以使用element UI，網上也有一些大佬給出現成的解決方案
最後再說支付，這塊網上有現成的代碼工具類，集成的並不多，因為可以需要申請，所以如果你想做啥具體的東西，可以在網上搜索方案
有啥具體的可以私聊我，可以一起討論
修煉IT基本功
現在java搭建平臺，碼雲和github上有很多腳手架工程，下來代碼進行二次開發就行了。最開始可能是jsp和servlet，後來慢慢的spring一站式框架就行了，慢慢該沒springw+springmvc+mybatis,在到這兩年springboot的流行，加快了微服務的落地。而且用java構建平臺現成的方案有很多，網上有很多，值得你借鑑。支持java開發的框架也有很多，給你更多的機會選擇。
JAVA程序猿成長之路
如果會java的話，這個選擇沒有錯；
idea+springboot+shiro，熟悉這些技術棧就能開發簡單的項目了！
編程邊玩
看你的描述應該是大型應用，老實寫代碼吧，不要指望走捷徑，客戶隨便提個需求就能讓你痛不欲生，而且可維護性基本等於零！
