我最近很受12Factor應用程序的誘惑，因爲它是強烈的指導方針，我應該強制自己遵循。 因此，在我正在研究的項目中，我決定使用它們。 雖然我對我的代碼結構有疑問：12應用程序代碼庫因素我應該拆分
我有一個網站，只是創建新的工作，人們可以諮詢那裏的工作結果。作業排隊進入分佈式隊列（ftm Redis），工作人員完成每項作業並執行它們。 我決定拆分2中的代碼庫：
中間有一個節點包，用於封裝通信（排隊等），節點之間的唯一通信是通過Redis進行的。
所以我只是想確定這與12factor一致，因爲我正在構建一個分佈式系統。 如果不是我應該使用一個啓動腳本啓動一個或另一個在一個代碼庫中構建所有內容？
THX對您有所幫助
保持簡單，但並不簡單，然後纔有意義。如果你更簡單的將它全部保存在一個代碼庫中，那麼就開始吧。開發是一個反覆的過程，假設你做錯了，並準備在事物開始變得笨拙時做出改變。
不成熟的代碼（或工作流）優化（或抽象）總是不明智的。
我決定在分裂代碼庫2
好了，12個因素網站上的第一項說：「一個代碼庫跟蹤的版本控制，多展開時」
從你的描述來看，我不認爲有可能告訴你遵循指引的程度。
如果兩者都可以作爲獨立的軟件使用，並且可以這樣維護，那麼將它們區分開來可能是有意義的。 – 2013-04-28 21:48:24
是的讓我猶豫的是：「如果有多個代碼庫，它不是一個應用程序 - 它是一個分佈式系統。分佈式系統中的每個組件都是一個應用程序，並且每個組件都可以單獨遵循十二個因子。 – charly 2013-04-28 21:51:24
是的，這是一個權衡，沒有正確的答案。列出您可能接下來要添加的功能列表。有多少人需要觸摸兩個代碼庫？如果它是其中的大部分，那麼請考慮將它們加入1回購。 – BraveNewCurrency 2013-04-29 02:36:31
這是真的。但是，將其放在單個代碼庫中會使其依賴於不存在的依賴關係（例如，我正在考慮express）。但確實有一個代碼庫會讓事情變得更簡單，包括部署。 – charly 2013-04-28 21:56:17
我想我會從一開始，當你發現你可以將它們作爲一個應用程序系統而不是一個應用程序來分開。我們經常在heroku上做到這一點。我們將開始編寫一些東西，然後注意到應用程序組件之間存在不必要的耦合，並在重構它們時將它們分成應用程序系統。 – 2013-04-28 22:03:44