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