開發一個業務邏輯複雜的系統，應該怎麼樣設計才能使項目的擴展性更好？

看到一篇好文章，收藏一下

我在知乎關於《開發一個業務邏輯複雜的系統，應該怎麼樣設計才能使項目的擴展性更好？》作的回答。

既然業務邏輯複雜，那意味着項目前期的業務建模、需求分析、分析設計極爲重要，直接拋開這幾個階段進入技術實施開發階段，無論套用什麼設計模式、架構模式，系統的擴展性確定難以保證。

項目的擴展性雖然最終體現爲系統架構、技術實現的擴展性，但系統擴展性的根源在於系統業務架構及業務模型的擴展性。你們常常罵xx系統爛、擴展性差，大都將緣由歸結爲技術實現爛，但總結那些成功的大型項目或產品的最佳實踐，緣由都會有：某某是業務專家，對xx業務很熟悉，可以銜接業務與技術。所以一個好的項目角色中，應該有行業專家/領域專家、業務過程分析師、系統分析師、軟件架構師等角色，從業務架構、信息架構、技術架構保證系統的擴展性。

具體怎樣進行業務建模，搭建良好的業務架構和業務模型，從而爲技術架構、信息架構、技術實現奠基良好基礎，有一些較爲成熟的軟件開發過程可供參考。例如 RUP（Rational Unified Process，統一軟件開發過程)。一個標準的RUP工做流程包括：業務建模，需求分析，分析設計，實施開發，測試，部署，配置和變動管理，項目管理，環境。固然RUP只是一個方法論，且過於龐大，大部分項目很難完整執行其過程，須要根據實際狀況進行裁剪，但其方法論對於複雜業務邏輯系統的建設具備指導意義。像互聯網產品設計中經常使用的用例分析技術就源於RUP。

所以對於題主描述的一個複雜系統，標準的過程應當在業務建模，需求分析，分析設計，實施開發，測試，部署完整過程的分析設計（與開發語言無關）或實施開發（分析設計的成果映射爲具體語言，例如Java、.NET等）階段才考慮設計模式、架構模式的引入。設計模式的使用會經歷僵化->固化->優化的階段，相似禪修中「看山是山、看水是水」的三個階段，才能體會模式的運用之妙。

值得強調的是：若是是偏交易（例如支付、金融）的系統，在考慮擴展性時候，必定要將信息架構、信息模型的擴展性歸入到考慮範圍，此類系統數據模型相當重要，也不可能頻繁變更。

上面描述方法的特別適用與傳統軟件、系統集成等需求偏穩定的項目，對於互聯網偏創新性的項目就不必定徹底適用了，此類項目的現實狀況以下：業務模式不肯定，會不停試錯，驗證模式；需求不停變化，要求可以快速響應；全新的行業，沒有行業專家，沒有行業標杆可借鑑（至多有跨界標杆可參考）；此時候，相似精益創業、Scrum之類的敏捷開發模式更適合，但對於複雜的業務而言，業務建模->需求分析->分析設計的理念仍然值得參考借鑑。

最後，最最重要的是：完美系統的架構和擴展性是管理出來的、持續重構出來的。正如各大城市馬路不停翻了再修、修了再翻的命運同樣，中國大部分公司後任會不停否認掉前任的架構、系統，推倒再來一遍，而後等新系統剛開發出來不久，還沒有上線或上線運營一段時間後，再換一幫人繼續折騰，而後。。。

總結這麼多年的經歷，深入體會到：再爛的系統和架構，若是可以強化管理、持續積累、持續重構、持續完善，都可以有機會成爲完美的系統，完美的系統不在於其架構的牛逼和完美，而在於：符合公司的業務模式，可以完美支撐公司業務的高速發展和市場需求的快速響應。