我正在看書Applying-Domain-Driven-Design-Pattern。客戶訂購,或訂購到域名模式的客戶
在其模型設計,它具有階保持參照客戶,但如果是我做設計,我將可能有客戶保持基準訂購。
所以,問題,設計單向關係時,如何判斷方向?
我正在看書Applying-Domain-Driven-Design-Pattern。客戶訂購,或訂購到域名模式的客戶
在其模型設計,它具有階保持參照客戶,但如果是我做設計,我將可能有客戶保持基準訂購。
所以,問題,設計單向關係時,如何判斷方向?
我想,如果這是一個訂單處理系統中的訂單是業務層次的概念和客戶提供如何處理訂單的背景下,那麼OrderService需要有訂單指誰取得了訂單的客戶。另一方面,正如其他人所指出的那樣,客戶可以查詢其訂單。這可以在服務檯的客戶服務系統中進行。在這種情況下,我可以看到需要客戶擁有許多訂單的CustomerService。
答案是由應用程序的功能驅動的。如果您需要按客戶查詢訂單,那麼您的方法是正確的。但是,如果客戶被他們的訂單查詢,那麼模型設計是正確的。
如果您需要做兩件事,那麼它是一個雙向的關係,你可以選擇將其建模爲多到很多。
結構服務一些功能。
也就是說,想想你的班級將如何使用。客戶會被詢問其訂單嗎?訂單是否會被客戶查詢?如果兩者都是,那麼你需要一個雙向關係。