需要建模領域建模

Question

所以，我想獲得一些關於如何適當建模業務邏輯域的建議。我試圖建立一個相對較大的系統，其中包括項目和人員（迄今爲止沒有什麼太可怕），但是沒有進入太多的NDA信息。現在我在Rails中構建它只是爲了快速獲得某些內容，但最終我會將其切換到Ember.js/JSON應用程序（對於這個問題不是那麼重要）。所以系統有幾種不同類型的「人」 - 有「用戶」（實際上可以登錄系統的人）和「聯繫人」（有關人的信息，如電話號碼，地址，電子郵件等）。這兩者分開的唯一原因是它們在邏輯上不同（登錄時不需要聯繫信息，並且不是每個「聯繫人」都需要登錄信息，或者應該可以登錄）。一個問題就是，將這兩個實體分開是合理的，還是應該使用一個廣泛的平坦對象與所有字段來對兩個登錄進行建模（並且我正在考慮Devise添加的所有字段這裏）和所有的領域做聯繫信息。

此外，還有項目。項目以不同身份作爲「接觸者」;一個項目可能有「Fred」作爲主管或經理，「Diana」作爲客戶。另一個項目可能（儘管不大可能）將「戴安娜」作爲主角，「弗雷德」作爲另一個角色。關鍵是每個聯繫人在每個項目中扮演的角色都是流動的。有幾個角色需要填補項目的有效性（好吧，不一定有效，但是有效）。

最後，一個扭曲，該應用程序是多租戶。因此，系統本身具有多個擁有自己的客戶的「客戶」（缺乏更好的術語），並且所有（頂級）客戶數據都必須嚴格分區。

現在，這裏是我在做什麼：

1. 織補附近的一切上有一個「CUSTOMER_ID」現場，讓我能範圍由（我自己）的客戶的所有要求。
2. 如上所述，「用戶」（可以登錄的人）和「聯繫人」（關於人的有用信息）是分開的。一個「用戶」必須有一個「聯繫人」，但「聯繫人」不必與「用戶」相關聯（在Rails中，我通過說用戶belongs_to聯繫人來關聯這個）。這是我不是100％肯定我做得對的第一個地方。
3. 項目和聯繫人多對多地連接（通過連接表），以便給定項目可以有多個聯繫人（反之亦然）。連接表包含一個「角色」屬性，以便我可以說出聯繫人在項目中扮演的角色。這...起作用，但它使SQL非常笨重（我擔心，速度很慢）。誠然，AREL爲我管理大部分SQL，但仍然爲了獲得體面的查詢（並避免N + 1問題），我必須做很多.joins/.includes調用，這對我來說聽起來像是一個漏洞抽象。

所以，我會放棄它，並以我開始的結束：任何人有任何建議或提示如何正確建模該系統？我甚至會回答「哥們兒，這是一個複雜的系統，但你正在做你能做的最好的事情。」 :)

謝謝！

Answer 1

下面是我將如何解決它...

首先，圖是一切！也許你已經完成了這個或者沒有完成，但我總是創建一個圖表，展示所有不同的參與者（在這種情況下，用戶，聯繫人，客戶和客戶的客戶）並繪製他們的關係。

其次，我不會分開用戶和聯繫人。如果聯繫人成爲用戶會怎麼樣？如果用戶下降到聯繫人怎麼辦？等等，這些都是你必須問自己的所有問題 - 那些「假設」的情景，雖然現在看起來不太可能，但可能會在以後出現。如果用例發生變化，您希望系統儘可能靈活。

所以，我會創建一個「用戶」表，並給他們一個權限列。這個人是用戶還是聯繫人？如果該用戶是用戶，則不要求提供聯繫信息，但如果他們是聯繫人，那麼這是必需的，但他們無法登錄。另外，如果用戶既是用戶又是一個聯繫人。

然後，我會爲顧客的多對多使用案例爲客戶提供單獨的「關係」表。例如：

| ID | UserID | CustomerID | 
----------------------------- 
| 1 |  2 |   3 | 
| 2 |  2 |   4 | 
| 3 |  2 |   5 | 
| 4 |  7 |   6 | 

UserID是父級客戶的ID，而CustomerID是子級客戶的ID。然後你可以限制誰看到了什麼。

對於您的項目問題，同樣的事情，我會製作一個名爲ProjectRoles的具有項目ID，用戶標識和角色名稱的單獨模型/表。在確保表格設置穩定/持久和加載查詢之間保持良好平衡。我寧願它第一次是正確的！