我的做法目前是這樣

1.site-config部份通通寫入到資料庫內 (參考Wordpress MultiSite)
2.網站的功能開放跟不開放，也是透過 ACL+config來設定 (參考Wordpress MultiSite)
3.業主如果有提出申請要自架私有雲，更新的部份我在系統上有留一隻 php 做 curl去擷取公有雲的版本是不是跟私有雲的版本有差異，由業主自行決定要不要更新 (可以利用RSS等，參考Wordpress的做法)，當然，還得去做版本差異的各種一鍵升級的script (還是建議參考wordpress/Joomla這類的CMS的做法)
4.客制化的程式都用Composer載入，只要Framework記得 auto_load就好，framework的routing也要實做Dynamic routing (客制化的模組通通都從db做好設定跟管理)
5.多語系改以前端JS做 string_replace來完成 (參考各大訂房網站系統的實作方式)，預設語系字典也可以在config裡面寫好

總而言之，既然只想要做單一版本研發，又不想失去需要客制化的客戶，就把所有客制化當成third-party套件來做，但是自己的系統還得在設計時做一個 default_value 的概念，以Laravel的例子來說，env('MAIL_DRIVER', 'smtp') 預設值為 smtp，但可以透過 .env file去設定 'MAIL_DRIVER' = mailgun去覆蓋，然後不同業主客戶在各自的.env file就有不同的 MAIL_DRIVER 的value，更新的時候只要避開 .env file被更新到就可以了 (乾脆把.env file轉到DB內更好)
shopline在公有雲上的實作方式我是不知道，但是如果說以Laravel來實做的話，我會把laravel Project透過 apache實做multi-site share one code，這個方式請參考 wordpress multisite的方式，有各種技巧可以達到

但上面提到的做法需要把工作切得很細，某種程度上投資成本還滿大的，RD的耐性是要很足夠的

以上，小弟淺見

這是很常見的做法, 通常稱做: Multi-tenant, Multi-Company, Multi-Vendor.....面對多用戶的大型應用系統都有這種能力, 不只有電商, 還有: ERP, CRM, Email, 網路空間.....等等...

別的不說, 一些跨國集團裡面, 自己就有 2,30 家子公司, 如果是集團作帳, 難道要各子公司各買一套 ERP, 再把所有報表輸出後, 送到集團總部, 叫總管理處自己匯總嗎? 集團沒這麼笨, 只要買一套可支援多公司別的 ERP, 就可以讓所有子公司都上來使用屬於它們自己的功能....

架構規劃得好的, 只需要一套程式, 就可以給多用戶使用; 功能啟閉都是在資料庫裡面註記, A 客戶可以用: 1,3,5,6,7,8 功能, B 客戶可以用 4,5,7,8,9 功能, 畫面出現每一張選單之前, 後台程式要先跟據資料庫的註記, 組出適合這個客戶的畫面, 再顯示出來.

所以全部的顯示畫面都是經過運算之後, 即時動態產生的, 不是一隻隻寫死的網頁檔案, 這樣才能根據客戶的類別, 即時顯示不同的畫面...

當然, 如果沒有這種規劃能力的話, 那也可以很原始的: 一家客戶給一套專屬原始碼, 然後根據他的需求去客製他專屬的原始碼; 不過, 這樣管理上百家各自不同的原始碼, 就已經天昏地暗了, 想要管理上萬家客戶, 會是一場災難....

網站語言問題?

i18n

跨國伺服器問題?

CDN ?

申請人如果要客製化呢?

就客製化, [shopline](https://shopline.tw/faq/features)也有提供

總不可能有多少業主就多少份程式碼吧？

可能, 看你的規劃, 而且你又有業主都有自己的伺服器的前提下

裡面有 function 需要更新怎麼辦?

看你是代管Server還是啥的, 不同情況不同做法

業主都有自己的伺服器,在同一份的情況下，要怎麼針對這些業主做數據庫連接、網域、金流甚至語言的客製化?

如果業主都有自己的伺服器了, 就照一般流程做

有 config 檔案是所有業主的數據，根據該伺服器綁定的域名做判斷
那這樣這份 config 不就大家都看得到了

為什麼這東西會出現在某個業主自己的伺服器

只是我好奇到底是怎麼管理這些程式碼才是對的

你要先確定你網站到底是提供"服務"給客戶(登入, 權限控管)

還是就是幫客戶寫他專屬的網站(類似外包)

假設某一個功能是Ａ業主要的, 但是ＢＣＤＥＦ業主不要這功能，這怎麼解

1.提供服務的網站 => 權限控管

2.幫客戶寫他專屬的網站 => production的時候就不應該包進去

總結

shopline看起來是走提供服務, 代管Server的方式

所以我想他應該是用權限來控制每個客戶能使用的功能等

如果你是想寫這種網站

那你一開始的出發點就不太對

你不只是設計一個電商網站

而是設計一個管理電商網站的網站

除了商店功能的實現

你還需要管理這些商店的功能實作

這種應該也不會出現客戶有自己Server的情況

像樓上大神說的

規劃很重要

以上拙見

我不說比較專業性的話，就單純白話的做法讓你知道一下。
一般來說，這區分如下的做法

1.同主機區分法：
你的程式碼就只有在一個地方，但用域名或是特規key的方式。利用區分資料庫或是其它特規處理的方式來做分開或共用使用。這樣子的做法則是需要你的商家都得到你的主機上。商家只能申請使用權。
好處是程式更新是所有的商家一起更新。缺點就是功能的部份比較無法自定義化。雖然可以用類似插件或是模組的方式來決定商家需要的功能有哪些。
現在有很多線上的erp系統大多會這樣做，你只是租用其服務。對商家而言是可以省下買主機的架構。但資料的安全性就有很大的考量因素存在。

2.中央server連動處理：
一般這種做法是會區分伺服端及客戶端。客戶端的程式碼可以提供下載給客戶安裝使用。
可是客戶端的部份連接還是得利用server端來做連動處理。這樣的好處是能保護你的程式碼不會全給客戶，並且在程式更新時可自動化的連動更新。依購物車而言，像是一些信用卡的機制則可利用你的server來做服務，不需要透過客戶端的server。
不過目前已經很少看到這樣的模式。大多數都是應用在多分公司的情況下。很少在應用程式中看到這種模式。大多數而言，只是為了公司及分公司的情況下才做這樣的規劃。這可以確保資料數據的統一化及個別設定規劃。目前比較常看到的設計還是屬於erp居多。

3.程式更新版本處理
跟第2點的做法有點類同。但性質不太一樣。程式碼是只有客戶端獨立性的東西。server這邊只有單純的程式版本控管的程式。不負責其它追加的服務。目前很多論壇、blog、購物車..等單機式的應用程式都是用此方式處理。客戶可以在後台看到目前的版本到哪邊，自已決定是否需要下載更新。
我們的程式就是單純的修改好之後放到server，並修正新的版本號提供給客戶自行處理。
這種方式是目前比較常見的方式。當然其缺點就是程式碼是要直接給客戶的。說好聽一點可以讓客戶做二次開發處理。說難聽一點，就是一種服務性買斷的方式。
絕大多數而言，這一類的產品，大多數來說幾乎都沒技術的支援。(有些可以付費尋求技術支援)
有些還有區分更新權跟使用權。也就是說你依然可以在未來更新你的版本，但客戶在更新期限超過的情況下，就得另外再付費。(免費的就除外了)

大約目前的性質是如此。我早前設計的購物車是有第1點做法跟第3點做法。

假設某一個功能是Ａ業主要的,但是ＢＣＤＥＦ業主不要這功能，這怎麼解？你還是用同一套程式碼....

我們都接不同性質的案子,用同一套程式碼,且都放在客戶主機,客戶的所有操作介面與邏輯運作都放在他們的私有雲資料庫.
個人的看法是每個案子的需求可能會相似但都不會一樣,用同一套流程與邏輯不可能應付所有差異的需求,如果客戶有使用,也都是用適應與將就的想法去使用.

其實,
沒有完美的程式,
很多大型程式設計完之後也是一直在改進,
這種東西就是經驗的累積,
其實很多人都是先去大公司打滾,
很多東西也只有大公司才有機會遇到,
有了一定的經驗之後再出來做,
來這裡問大概只能問到概念,
真正的東西還是需要多實作多改進.