軟體系統随着業務的發展，變得越來越複雜，不同領域的業務所涉及到的知識、内容、問題非常非常多。如果每次都從頭開發，那都是一個很漫長的事情，且并不一定能将它做好。團隊協作開發時，沒有了統一标準，大家各寫各的，同樣的重複的功能到處都是。由于沒有統一調用規範，很難看懂别人寫的代碼，出現Bug或二次開發維護時，根本無從下手。（無架構不堪回首的黑暗日子請看前面章節的講述）
而一個成熟的快速開發架構，它是模闆化的代碼，它會幫我們實作很多基礎性的功能，我們隻需要專心的實作所需要的業務邏輯就可以了。而很多底層功能操作，就可以完完全全不用做太多的考慮，快速開發架構已幫我們實作了。這樣的話，整個團隊的開發效率可想而知。另外對于團隊成員的變動，也不用太過擔心，快速開發架構的代碼規範讓我們能輕松的看懂其他開發人員所寫的代碼。
搭建快速開發架構時，我們要如何定位
是不是快速開發架構的擴充性、可移值性、功能越強大就越好呢？
好的快速開發架構是相對的，它都有自己特定的應用領域，合适才是最好。
個人覺得在實際開發中要根據具體情況來看的，因為功能越全面它的複雜度就越大，所需要的開發人員能力和技能就會要求更高，付出的成本也就最大。比如做一個還未發展起來的電商網就想 将系統做成像京東那樣，直接用京東分子產品分布式的架構來開發，那得怎麼來組建這個團隊？更不用說開發成本了。就算團隊有能力做到，也沒有那個必要這麼去做，因為從成本預算和開發周期等方面來看，得不嘗失，更多的可能項目還未完成公司就給拖垮了。
一般來說，一個中小型項目，1到5人左右的開發團隊，使用一般的三層結構就可以了，不用去細想架構要分三層還是五層，每個層之間要怎麼實作解耦，要用什麼設計模式.....因為當今飛速發展的網際網路時代，快才是王道，做一個中小型項目能用一周完成的，絕不能拖了一個月還未做完。人工與時間成本才是重點中 的重點，唯有快才能更好的生存下來并壯大。至于擴充功能、接口、分布式、并發、大資料......等等問題，實際上過早考慮太多并不是好事情，有經驗的程式員在寫這個快速開發架構時早已留下擴充方案或思路，而沒到這一層次的開發人員你想再多也可能想不明白，還不如先做出來積累一定經驗後再慢慢學習，慢慢更新架構。
當然也不是說設計架構時不用考慮高内聚低耦合，而是要根據自己的能力與經驗來設計出自己能把控的架構出來。因為架構不是開發出來後就不再變動，它也需要不停的進行更新，将你所學到的新知識新技術融合到架構中，使它的功能更加強大，更加健壯。而對于自己不能把控的快速開發架構，在團隊協作開發和上生産環境後，你就發現有一大堆的坑等着你去填埋，這種架構隻能拿來先練練手，有空再慢慢完善。
快速開發架構通過小步快跑，不斷的疊代更新來慢慢擴充的，當項目上生産環境後，根據新的需求和所碰到的問題，去不停的調整，最終越來越強大。所有架構都是從1.0版本到2.0、3.0......發展而來，而不是直接跳過最初版本到最終成熟版本。
是以說我們在建立一個架構時，必須根據我們目前個人的技術能力、團隊成功技術水準、時間、投入成本、項目現狀（規模與需求複雜程度）、以後的發展前景來決定所要開發的架構的最終設計方案。當然也不是說不能一步到位，心有多大世界就有多大，隻要個人能力和團隊能力配得上，老闆資金成本雄厚，時間充足，直接上大項目使用超級架構也完全沒有問題。