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