對業務流程建模而不是對實體建模 - poweredbybeard

這一直持續到我的職業生涯，雖然我個人已經改變了，但我仍然看到這種建模方式隨處可見。對於簡單的系統來說，這很好。但隨著你的領域的複雜性的增加，它往往會導致一個神的物件。

如果你為一個實體建模，從設計上來說，你是在為一個會活得很久的東西建模。例如，在醫院裡，你可以為一個病人建模。但是，你可以對病人執行許多動作，這些動作會導致實體的大小增長。不久之後，你就會在資料庫中發現一個由大型資料圖支援的大型病人物件，這很糟糕。

在你的系統中擁有這樣的大型實體使得事情難以改變。在重構的時候，你會有更多的副作用需要考慮，而且改變設計也很困難。

對業務流程建模
一個更好的選擇是對業務流程進行建模，而不是對實體進行建模。以病人為例，你可以對病人在醫院的旅程進行建模，而不是對其進行建模。你可以把入院或出院作為一個單獨的過程來建模。這些模型有的大，有的小，但它們都有一個共同點：它們是有時間性的。它們有一個開始和一個結束。

這使得控制邊界和阻止它們成為大型神物變得更加容易。它還帶來了其他好處。最值得注意的是，這就是人們的思維方式。企業以流程來思考，如果你能在程式碼中建立模型。

這種方法需要考慮的一點是，你需要對領域有一個很好的理解。你需要有領域專家供你使用，因為否則，沒有他們，你就只是一群開發人員在猜測業務如何運作。

如果你有機會接觸到領域專家，我強烈推薦將Event Storming作為發現這些流程的一種方法。這是領域專家和開發人員互動的一種很好的方式，我推薦你閱讀Ablerto Brandolini關於這個問題的書。

最後，這種思維方式在構建事件源eventsourcing系統時效果非常好，因為這些系統經常受到相同問題的困擾。當開發者對實體進行建模時，他們通常有大量的流，需要很長的時間來融合水化。對流程進行建模將使這些流保持簡短，並在它們不再相關時給你一個處置它們的選項。