如果單就一個商品，不會做客製化修改，或者鮮少做客製化修改，那七層式架構是最精簡最完美的：詳細介紹

但如果產品是一個基於套裝模式（就是有一個共用版本）下，經常性地做客製化修改，那就會相當難處理。

最原始的處理方法是所有Code寫在一起，只判斷公司名稱，哪一個公司做哪一條路線，這種方式會程式相當笨重且相當難維護。

因此昨天與o1-preview討論以後，可以在會被替換的部分，增加一個Factory層，比較容易被替換的以後端來說，DASC四層（Data、Access、Service、Controller）都有可能會被替換掉，所以會變成8層的架構，如果各自的Factory算一層，或者是Factory全部算一層，四層的程式碼挑選與export全部都是在同一層，這樣會比較漂亮，就是五層架構。變成DASCF五層式架構。

然後前端的DAI（Data、Access、Interface），如果是以Angular來講Interface相對的難處理，而Data和Access都會需要Factory。所以會變成DAFI四層。

這樣的話是九層式架構，也就是跟o1先行版的模型討論，我們公司的技術框架就這樣確定下來，而且結合不管CI/CD甚至自動封裝、發布、通知客戶、客服追蹤、技術支援、滿意度調查，全部都可以做成一系列流程。

o1先行版就有這樣的思考能力，我實在很期待Strawberry這個模型，這樣我公司除了我以外在我退休之前不需要別的研發工程師，只要會用AI的AI工程師就好。