以下招聘系統上應用DDD

Question

我有應用DDD大多數網上找到的例子是不是太複雜或過於簡單（產品/ ItemOrder型）

我有一個招生制度的問題， 一個部門可以有一個職業（專業不能沒有一個部門就存在） 一個招聘渠道可能有一些招聘來源（一個招聘來源不可能沒有招聘頻道） 現在我有一個申請人不能沒有專業而不能存在並且不能存在沒有招聘來源。 此外，如果沒有候選人（但是我看到這樣通過domainevents接收通知的面試日曆另一個有界範圍內的面試部分）

我想了解如何提取不存在的面試什麼是什麼在DDD AggregateRoot等方面（這裏我相信我有兩個競爭對手部門和招聘頻道） 鑑於我選擇了其中一個，我將如何處理另一個？

也許我錯了。如果任何人都可以照亮我，這將是非常有益的。

Answer 1

似乎，你沒有ask right questions給你的領域專家。 你在這裏得到的所有信息都是可以/不能與別的東西一起存在的東西。 你知道what does職業，部門，系統背景下的面試嗎？
您的要求都是關於數據（表格關係），而不是behaviour本身。

在DDD中，你把verbs的過過名詞。你把它們作爲你的聚合方法。然後，根據事務邊界選擇聚合邊界（它是否需要與此相關，或者可以等待？）。

• 首先詢問您的域專家有關約requirements的系統。它應該提供什麼功能。
• 然後詢問user stories，這只是系統的簡單用法。但是don't talk about the front！ 這是not user story - 當用戶點擊購買按鈕並提交表單，然後他購買產品 這可能是你user story - 作爲一個用戶，當我買車，我一個VIP我應該得到20％的折扣，所以我會再拍買不久

從用戶故事，你可以提取一些有用的信息，這是超過例如：「商店可以有多個產品，但產品也可以有一個標題」 我希望你能明白一點。

關於如何聚集模型，看看這裏Vaughn Vernon

Answer 2

也許我會約了錯誤的方式。如果任何人都可以照亮我，這將是非常有益的。

步驟＃1：尋找無處不在的語言。與你的領域專家一起坐下來，並且非常小心地注意他們所談論的實體。

例如：

申請人不能沒有職業存在和不具有招募源可以不存在。

這似乎有點奇怪。我期望一個申請人是一個人，而人們當然沒有「招聘來源」（不管是什麼）。如果您要說如果沒有招聘來源，應用程序不可能存在，或者更好的是應用程序總是由招聘來源引用，我更可能相信您實際上正在與該領域的專家交談。

域模型不描述結構;域模型控制變化。

除非您瞭解模型允許的更改，否則無法對集合進行明智的設計決策。或者更好地說，哪些變化是允許的 而不是。

識別實體是建模工作的一部分，但您確實需要注意哪些實體從屬於該模型。例如，考慮客戶vs賬戶;該模型可能無法控制客戶（您的模型能否阻止人們更改他們的名字或移動？），但它可能能夠控制帳戶（暫停，跟蹤促銷優惠，提升爲VIP身份）。

啓發式：如果您的業務無法控制它，那麼您的模型也無法控制它。