從一個帳戶轉帳到另外一個帳戶的 轉帳匯款 使用案例中，我們可以 建立一個用於 提款 和 存款 的 帳戶(實體）模型、一個實作了使用案例並且負責變更領域模型狀態的服務、一個輸入轉接埠介面、一個輸出轉接埠介面，一個實際上外部呼叫傳入的轉接器
將 輸入驗證 安插在 輸入模型 (SendMoneyCommand)，我們便可以對於使用案例實作的周圍建立一層防腐層，且依據六角型架構來看，輸入模型 (Dto) 是屬於 使用案例 API 的一環，並不會導致職責擴散到使用案例中。而安插在 輸入模型 驗證 還有一個好處 就是 一個使用案例可能會被多個轉接器 ( Web Controller 或 Command Line) 呼叫，如此一來，就能避免每一個轉接器都必須去實作驗證。
而對於不同的使用案例，請視為不同的輸入模型 (假的重複)，這樣才能讓使用案例更準確，也能避免使用案例之間出現耦合。
而對於不同的使用案例，也請視為不同的輸出模型 (假的重複)，並且只回傳最低限度的資料，回應過多的資料往往代表可能含了其他的使用案例。
而區分業務規則驗證 和 輸入驗證，最簡單的區分方式，就是 “業務規則要驗證時需要依據領域模型當前的狀態而定”，輸入驗證則不用。 或者可以形容：輸入驗證是使用案例的 “語法驗證” ， 業務規則是使用案例的 “語意驗證”。
貧血模型 和 充血模型
貧血模型就像是 面向過程的手段，實體本身沒做多少事情，通常只是欄位狀態的保存，而領域邏輯在被實作在使用案例類別內。
充血模型則是相反，大部分的領域邏輯都會是實體承擔，使用案例只是作為進入領域模型的進入點，只是來表達動機與目的。
