成熟的項目架構設計是什麼樣的?

本人自學，最近做了個人項目，為期兩個月，是個 b2c 商城，技術棧是 sass、jquery、thinkphp，經過一套摸索下來，勉強能運行，項目大部分東西是自己瞎想出來的，沒怎麼參考到前人經驗，因為找不到，我發現自己對項目開發流程等沒什麼概念，這些似乎是屬於架構的東西？想查些資料學習，但這方面的資料屬實難找（當然也可能是我查的方法不對），因此提問，下面是幾個具體的問題，可能會不定期更新。
一、項目開發流程的基本組成部分有哪些？目前我的認知裏是需求分析、設計整體業務流程、設計數據模型、代碼實現。可能用詞不太標準，「設計整體業務流程」、「設計數據模型」是我自己瞎想的叫法。
二、如何系統的、有步驟的確定一個項目的業務流程？
三、如何在初期確定項目整體的運作模型？即對項目整體的前期設計？這是個很難的問題，需要考慮的很全面，很容易出紕漏，因為這個「考慮」總是建立在沒做的基礎上，要在沒做時就考慮到整個項目的方方面面邊邊角角，既要想到「該有什麼」，又要想到「該如何組合、協調」它們，還要想到「某個部位具體的技術細節」，甚至想到如果以後要加一些東西，該怎麼預留位置，要做好這些，真的好難。
（新增）四、如何設計數據模型？或者說怎麼設計數據表？似乎很大程度上是基於經驗來設計的，目前我認為，根據前端的功能需要來設計數據模型比較好，也就是為實現功能而設計儘可能方便的數據模型。

關於第三個問題，經過這次項目的思考總結後，我有點見解，我發現讓前期設計與前端頁面編寫同步進行是個不錯的選擇，因為只編寫頁面模版並不需要多少數據支撐，想改也是很快的，而頁面模版能比較明確的反映出需求到底有哪些，需要什麼樣的數據模型，我覺得這對前期設計的幫助還是很大的，這是我這次做完後纔想到的方法，目前還未實踐過。
下面是我在本次項目初期時畫的一些腦圖，製作過程幾乎完全基於個人瞎猜，歡迎大佬評論指正，由於設計問題，其中退貨、優惠券、折扣部分最終並未完成：

這些東西是基於經驗來的的沒錯。你所需要做的就是，每當你有一個架構想法的時候，你就把它做出來，總結一下為什麼喫了屎，久而久之你的方法就成熟了。

一個成功的架構，要易於維護，易於擴展，還要能經得住傻逼同事的折騰。

謝邀。

一套系統的建立，大公司和小公司可以說是大相徑庭。

大公司由於更加註重流程，所以很多人自嘲Java，.Net各種代碼都不寫，只寫PPT和Word，從而產生了一個崗位叫PPT項目經理。沒辦法，CMMI要啊，這東西對流程、文檔看的特別重。對於大公司而言，不一定需要最前沿的科技，最花哨的寫法，但是要最全的文檔，最嚴謹的流程。

小公司則不然，更加註重的是結果。文檔林志玲，產品郭晶晶（沒貶低的意思，就是。。順口？），用戶不買單，對於小公司來說就是致命打擊。

目標不同，過程不同。

還有你所提到的框架，任何一家科技公司，可能都或多或少有幾套自己用著最順手的框架。而一個合理的框架應該包括以下幾個要素

順手，如果一家公司的技術棧偏Java，那如果非逼著程序員去用其他語言框架趕工期，沒必要。
不應過分複雜，碼農界有一個不太好的風氣，就是互相攀比誰的代碼更讓人看不懂（或者說是誰的代碼看起來更酷炫），實則這一風氣並不值得讚揚。這就像做一個漢堡，並不一定非要在兩片麵餅（是這麼稱呼麼。。）之間加8層肉，7層蔬菜，還加上各種香料，這好喫麼？我覺得一層雞腿肉，一層蔬菜就已經很可口了。
盡量選擇有一定用戶基礎的框架，這樣遇到問題也能比較方便的解決。
做框架是在做減法，如果使用了框架使得開發過程更加複雜，那框架的意義就沒了。
層級架構明顯，比如.Net做WebAPI的項目經常會拆成Controller，BLL，DAL，Model，Converter，DB，DataEntity等幾層，每一層都各司其職，用起來非常清晰。
並不一定別人覺得好的框架就適合你，也並不一定非要去追隨別人的腳步選擇一些GitHub上的高星產品。適合的纔是最好的。

歸根結底一句話，用框架的目的是讓代碼規範，開發流暢，而不是炫技。

對於你的一些其他問題，我也有部分個人見解，是否一定要在業務邏輯想的特別清楚的情況下再開始動手寫代碼？

我並不敢苟同，因為無論怎麼想，總歸會在製作的過程中遇到問題。我更建議在對大局有一個基本的認知以後，就可以先從前端開始製作。

不要先建立資料庫！

對於一個需求還並不非常明朗的小項目而言，首先要做的是界面上的內容足夠用。比如你現在做的商城，可能先照著淘寶的頁面畫了個類似的，有一些初始的數據欄位，在你做的過程中會慢慢的發現其他問題。這時候會發覺，之前的資料庫結構可能不太對，需要增加欄位，而欄位增加在哪，直接增加表欄位還是加個新的表，等等問題都會在你踩坑的過程中一一迎刃而解。

我作為獨立開發者，對於一個新項目，也會運用類似的思考方式。

我要做什麼
做了幹什麼用
大概什麼樣子
編造些假數據
頁面基本敲定，後臺配合資料庫一起開發

個人深刻的感受到，對於項目而言，怕不思考，但是也怕過度思考。該出手時就出手，寫，才能發現問題，想，只能發現表面問題。

技術棧應該如何選擇

看你做這個練手項目的真實目的了，如果只是為了練手，那麼jQuery，thinkPHP之類的沒有問題，練習一下挺好的。但是如果你的目的是最後可以上線，或者說稍作修改可以上線，那麼技術棧的選擇就有點問題了。畢竟當今世界，網頁端的流量已經很少了，可以嘗試學學做App，或者小程序之類，畢竟手機纔是當今市場最大的一塊乳酪。

首先不得不贊一下，做的不錯。圖設計的都挺漂亮的。

弱弱的問一下，有沒有sku的設計？

開發流程嘛，每個公司都不太一樣，都會根據公司的特點進行調整。

總體來說和你說的也差不多。

說一下數據結構設計的事。

理想情況下，注意是理想情況：

1,需求分析

2,功能設計

然後這裡出現分支，前後端同時進行。

前端就是你說的那些。

後端主要是模型設計，或者是資料庫設計，這個看是面向資料庫還是面向對象。

總之，資料庫設計的時候，關注的是需求和關係型資料庫的特點，盡量不要去想前端的需求。

這個要求就有點高了。

同理，前端設計的時候，也是想著需求和前端的特點。

然後呢，重點來了，前後端怎麼結合？介面怎麼設計？

其實這個纔是ORM的核心內容！

兩端都獨立設計好了之後，再考慮如何對應。

這麼做的好處是，可以把各種都特色發揮出來

缺點就是，難度有點高，有時候配不起來，雙方都得做出點讓步和妥協纔行。

所以簡單的開發方式就是，前端往後推，或者後端往前推。

其實說了這些吧，其實都沒啥關係用。

還是要開你以後的打算。

如果要去公司打工的話，那就看公司的規定了，公司說怎麼開發那就是怎麼開發。

除非公司讓你負責制定開發流程。

這個也就是看你自己的定位，你想負責哪個部分。

大公司，每個環境都設計好了，去了就是螺絲釘，然後一點一點接觸更大的範圍，如果有可能的話。

小公司嘛，就複雜了，各種情況都有。

如果你想自己創業，那麼就要下功夫去研究了。

如果有興趣的話，可以透露一下你的定位和想法。

你很厲害，超過了很多人了。

很多公司很多情況下，前期設計的再好，天天變都是可能的

唯有不變的是變化本身。

ui最噁心，由ui驅動需求和由數據驅動需求，最後互相妥協的更噁心。只要能插上話的，都會來說一說ui的事。

標準流程也有，產品經理先搞個大概，做出原型，然後前後端一起看看，修改，定板，評估時間，ui設計，前端評估。開搞。中途有少量臨時變更，討論，改。然後做得差不多了，測試進來，需求迭代。

以上是比較好的流程。實際中亂的一筆。今天這個想法，明天那個想法的是常態。隊友靠不靠譜，公司靠不靠譜很重要。

大多數人在一個輪迴又一個輪迴中罷了

具體的業務，商城是個很複雜的東西，支付，訂單，售後，購物車，這些都是比較難的，想清楚一個整個流程，並且這個方案是好多種的哪一種，比如售後，這個穿插在之前還是訂單之後，這個售後流程，還有退貨退款的各種情況。財務狀態和訂單狀態的各種情況。這個業務不是一個人能想清楚的。都是經歷很多次的磨合才能想清楚，到底有多少種售後模型，為什麼選了其中的這種。財務狀態和訂單狀態和售後狀態能對好都不容易（實際代碼中）了

開發流程中，很多的時間其實是，搞清楚人真正想要什麼的過程

開始這樣寫挺不錯了，業務流程設計中規中矩。但是不屬於架構設計的內容。架構設計首先是一種編碼規範，規定業務代碼的編碼方式和提高代碼水平以及一致性。許多人把業務理解成架構，這是不對的，業務驅動架構，架構為業務服務，架構高等論只是對自身的狂妄自大而已。

架構包含的內容有，資料庫訪問，緩存機制，編程語言選擇，設計模式（MVC），使用示例，測試示例，編碼規範。單體架構大概就是這樣。分散式，微服務跟複雜些。

ORM能不用就不用了，自己寫一個資料庫訪問類就好。緩存機制用不好全是坑，做好細節，哪裡用怎麼用要明白。語言最好是靜態語言，強制類型，對大家都好。示例編寫的好壞決定了業務編碼的水平高低，最好是業務代碼可以直接拷貝的的代碼，改改就能用的，新人上手塊不易出錯，代碼質量有保證。

不要拿現成的Spring，beego等待架構直接寫業務，根據自身業務封裝一層

不錯，但是，你的這個能力會在進入標準化流程後喪失。標準的目的是把人變成螺絲釘，讓一個組織可以做到只要保障了過程就能保障結果，有著大量的額外工作僅僅是為了上層可以觀察。至於螺絲釘的感受嘛，不好使就再換一個唄。

嘗試簡單回答一下問題：

一、項目開發流程的基本組成部分有哪些？目前我的認知裏是需求分析、設計整體業務流程、設計數據模型、代碼實現。可能用詞不太標準，「設計整體業務流程」、「設計數據模型」是我自己瞎想的叫法。

開發流程大致就是：需求、設計、開發、測試，具體執行又分瀑布、迭代（也有叫螺旋的），經常說的敏捷開發可以算在迭代裏。每個環節展開還有很多細節，感興趣可以參考CMMI或者RUP的文檔。

二、如何系統的、有步驟的確定一個項目的業務流程？

目前非專業人士用的最多的就是流程圖，專業一點的話就是用例法、用戶故事地圖等方式。這個展開說篇幅就長了。

三、如何在初期確定項目整體的運作模型？即對項目整體的前期設計？這是個很難的問題，需要考慮的很全面，很容易出紕漏，因為這個「考慮」總是建立在沒做的基礎上，要在沒做時就考慮到整個項目的方方面面邊邊角角，既要想到「該有什麼」，又要想到「該如何組合、協調」它們，還要想到「某個部位具體的技術細節」，甚至想到如果以後要加一些東西，該怎麼預留位置，要做好這些，真的好難。

考慮問題的思路還是從大到小，逐步分解。先確定項目的範圍和邊界（用例法可以做到），然後逐步分解、細化，這樣就不容易遺漏。至於以後要加的東西，現在不要考慮太多，不要過度設計。