一直追溯到我上大学的时候，我被教导要为实体或对象建模。对于一个业务问题，我被告知要寻找像 "汽车 "和 "人 "这样的东西，并在一些美化的层次结构中利用继承来为它们建模。
这一直持续到我的职业生涯，虽然我个人已经改变了，但我仍然看到这种建模方式随处可见。对于简单的系统来说，这很好。但随着你的领域的复杂性的增加，它往往会导致一个神的对象。
如果你为一个实体建模，从设计上来说，你是在为一个会活得很久的东西建模。例如，在医院里，你可以为一个病人建模。但是，你可以对病人执行许多动作，这些动作会导致实体的大小增长。不久之后，你就会在数据库中发现一个由大型数据图支持的大型病人对象，这很糟糕。
在你的系统中拥有这样的大型实体使得事情难以改变。在重构的时候，你会有更多的副作用需要考虑，而且改变设计也很困难。
对业务流程建模
一个更好的选择是对业务流程进行建模，而不是对实体进行建模。以病人为例，你可以对病人在医院的旅程进行建模，而不是对其进行建模。你可以把入院或出院作为一个单独的过程来建模。这些模型有的大，有的小，但它们都有一个共同点：它们是有时间性的。它们有一个开始和一个结束。
这使得控制边界和阻止它们成为大型神物变得更加容易。它还带来了其他好处。最值得注意的是，这就是人们的思维方式。企业以流程来思考，如果你能在代码中建立模型。
这种方法需要考虑的一点是，你需要对领域有一个很好的理解。你需要有领域专家供你使用，因为否则，没有他们，你就只是一群开发人员在猜测业务如何运作。
如果你有机会接触到领域专家，我强烈推荐将Event Storming作为发现这些流程的一种方法。这是领域专家和开发人员互动的一种很好的方式，我推荐你阅读Ablerto Brandolini关于这个问题的书。
最后，这种思维方式在构建事件源eventsourcing系统时效果非常好，因为这些系统经常受到相同问题的困扰。当开发者对实体进行建模时，他们通常有大量的流，需要很长的时间来融合水化。对流程进行建模将使这些流保持简短，并在它们不再相关时给你一个处置它们的选项。