資訊專欄INFORMATION COLUMN
摘要：看到一篇好文章，收藏一下我在知乎關于開發一個業務邏輯復雜的系統，應該怎么樣設計才能使項目的擴展性更好做的回答。一個標準的工作流程包括業務建模，需求分析，分析設計，實施開發，測試，部署，配置和變更管理，項目管理，環境。
看到一篇好文章，收藏一下
我在知乎關于《開發一個業務邏輯復雜的系統，應該怎么樣設計才能使項目的擴展性更好？》做的回答。
既然業務邏輯復雜，那意味著項目前期的業務建模、需求分析、分析設計極為重要，直接拋開這幾個階段進入技術實施開發階段，不管套用什么設計模式、架構模式，系統的擴展性肯定難以保證。
項目的擴展性雖然最終體現為系統架構、技術實現的擴展性，但系統擴展性的根源在于系統業務架構及業務模型的擴展性。大家經常罵xx系統爛、擴展性差，大都將原因歸結為技術實現爛，但總結那些成功的大型項目或產品的最佳實踐，原因都會有：某某是業務專家，對xx業務很熟悉，能夠銜接業務與技術。因此一個好的項目角色中，應該有行業專家/領域專家、業務過程分析師、系統分析師、軟件架構師等角色，從業務架構、信息架構、技術架構保證系統的擴展性。
具體怎樣進行業務建模，搭建良好的業務架構和業務模型，從而為技術架構、信息架構、技術實現奠定良好基礎，有一些較為成熟的軟件開發過程可供參考。例如 RUP（Rational Unified Process，統一軟件開發過程)。一個標準的RUP工作流程包括：業務建模，需求分析，分析設計，實施開發，測試，部署，配置和變更管理，項目管理，環境。當然RUP只是一個方法論，且過于龐大，大部分項目很難完整執行其過程，需要根據實際情況進行裁剪，但其方法論對于復雜業務邏輯系統的建設具有指導意義。像互聯網產品設計中常用的用例分析技術就源于RUP。
因此對于題主描述的一個復雜系統，標準的過程應當在業務建模，需求分析，分析設計，實施開發，測試，部署完整過程的分析設計（與開發語言無關）或實施開發（分析設計的成果映射為具體語言，例如Java、.NET等）階段才考慮設計模式、架構模式的引入。設計模式的使用會經歷僵化->固化->優化的階段，類似禪修中“看山是山、看水是水”的三個階段，才能體會模式的運用之妙。
值得強調的是：如果是偏交易（例如支付、金融）的系統，在考慮擴展性時候，一定要將信息架構、信息模型的擴展性納入到考慮范圍，此類系統數據模型至關重要，也不可能頻繁變動。
上面描述方法的特別適用與傳統軟件、系統集成等需求偏穩定的項目，對于互聯網偏創新性的項目就不一定完全適用了，此類項目的現實情況如下：業務模式不確定，會不停試錯，驗證模式；需求不停變化，要求能夠快速響應；全新的行業，沒有行業專家，沒有行業標桿可借鑒（至多有跨界標桿可參考）；此時候，類似精益創業、Scrum之類的敏捷開發模式更適合，但對于復雜的業務而言，業務建模->需求分析->分析設計的理念仍然值得參考借鑒。
最后，最最重要的是：完美系統的架構和擴展性是管理出來的、持續重構出來的。正如各大城市馬路不停翻了再修、修了再翻的命運一樣，中國大部分公司后任會不停否定掉前任的架構、系統，推倒再來一遍，然后等新系統剛開發出來不久，尚未上線或上線運營一段時間后，再換一幫人繼續折騰，然后。。。
總結這么多年的經歷，深刻體會到：再爛的系統和架構，如果能夠強化管理、持續積累、持續重構、持續完善，都能夠有機會成為完美的系統，完美的系統不在于其架構的牛逼和完美，而在于：符合公司的業務模式，能夠完美支撐公司業務的高速發展和市場需求的快速響應。
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/11704.html
摘要：而只需要調用對象完成業務邏輯即可。領域建模的好處面向對象封裝的相關操作都封裝在上，提高了內聚性和可重用性。對于這樣簡單的場景，這個建模就差不多了。這就是模型的統一。其功能性及說明性急速增強，而復雜性卻隨之消失。 showImg(https://segmentfault.com/img/bV62vN?w=677&h=393); 你還在用面向對象的語言寫面向過程的代碼嗎？你是否正在被復雜的...
摘要：而只需要調用對象完成業務邏輯即可。領域建模的好處面向對象封裝的相關操作都封裝在上，提高了內聚性和可重用性。對于這樣簡單的場景，這個建模就差不多了。這就是模型的統一。其功能性及說明性急速增強，而復雜性卻隨之消失。 showImg(https://segmentfault.com/img/bV62vN?w=677&h=393); 云棲君導讀：你還在用面向對象的語言寫面向過程的代碼嗎？你是否...
摘要：移動精英開發社群的第期，也是圍繞架構這個話題進行討論。本次我們希望結合實際開發中遇到的問題，來聊聊移動端的架構設計。這樣的模式改進一些，可能會更適合移動端架構。潘衛杰之前我們公司移動端的大項目就是插座式開發的，批量出各個行業的。 此前，58 同城的技術委員會執行主席沈劍在 OneAPM 的技術公開課上分享過一個主題，「好的架構不是設計出來的，而是演技出來的」。因為對很多創業公司而言，隨...
摘要：前言本文給大家分享的題目是基于微服務以及的高可用架構探索與實現。比如說年大地震的時候我正好在東京，當時在做一個金融系統的相關工作。那次大地震導致很多很多的問題，雖然大地震不是在東京發生，但是還是給我們的系統造成了影響。 前言 本文給大家分享的題目是《基于DevOps、微服務以及K8S的高可用架構探索與實現》。整個企業的高可用架構面臨很多的挑戰，面向微服務、容器化以及敏態交付，是我們現在...
摘要：導言耦合性，是對模塊間關聯程度的度量。模塊間的耦合度是指模塊之間的依賴關系，包括控制關系調用關系數據傳遞關系。 導言： 耦合性，是對模塊間關聯程度的度量。耦合的強弱取決于模塊間接口的復雜性、調用模塊的方式以及通過界面傳送數據的多少。模塊間的耦合度是指模塊之間的依賴關系，包括控制關系、調用關系、數據傳遞關系。模塊間聯系越多，其耦合性越強，同時表明其獨立性越差。軟件設計中通常用耦合度和內聚...
閱讀 466·2021-10-09 09:57
閱讀 470·2019-08-29 18:39
閱讀 811·2019-08-29 12:27
閱讀 3028·2019-08-26 11:38
閱讀 2667·2019-08-26 11:37
閱讀 1285·2019-08-26 10:59
閱讀 1376·2019-08-26 10:58
閱讀 989·2019-08-26 10:48
