在开发领域模型时，我可以看到两种主要的方法来思考类/实体的设计。第一个假设一个程序作为一种“模拟”现实世界中发生的事情。使用这种方法，您将拥有一个Customer类 - 例如 - 可能的方法与Customer可以执行的操作相对应。每当客户想要做某事时，都会调用相应的方法。另一种方法是将类设计为好像它们暴露给用户，然后他/她就能够“直接”创建和玩对象，将程序视为用户现实的一种扩展。通过这种方法，客户类可能没有任何意义，因为客户已经“参与”了。我读过一些文章，谈论在方法层面增加安全性，这似乎与这种方法一致，但我相信两者都是在野外使用。你怎么处理这个？
谢谢。
答案 0 :(得分：1)
在开发域模型时，您应该从不模拟现实世界中发生的事情。
真实世界过于复杂，您需要一个域模型来简化您的特定应用程序开发。我已经看到一些域模型被定义为“非常灵活”（非常抽象）或“现实”（这意味着过于详细和复杂而无法理解），并且都会导致项目失败。
域模型应该只包含与使用自己语言的代码表示的应用程序相关的领域专家知识（总是他知识的一小部分）。它应该在有限的背景下分裂，进一步降低认知负荷。
如果他谈论“火车”，您可以在您的域模型中拥有Train课程;如果他谈论策略，你可以在你的域模型中有一个Strategy类，但你不能在域中拥有一个策略类，因为你发现他称之为“玩家”的东西可以用strategy pattern
您可以必须模拟的是专家用于提供真实世界服务的“纸质流程”。
对于问题的其余部分，可以逐案评估，按应用程序进行应用。
例如，在我开发的财务应用程序中，不同的角色有时可以以不同的方式使用相同的概念。当我确定概念完全相同时，我使用bounded roles来表达差异。但请注意，这绝不会发生在实体上，只是为了重视对象和域服务。如果你发现两个角色谈论一个可识别的对象（也就是一个实体），你知道这两个角色共享的唯一东西就是对象的身份，但他们正在考虑不同的事情。
有界角色与您对ipothetical Customer类的看法类似。
答案 1 :(得分：0)
如果我理解正确你的问题主要是关于观点。答案是：您应该使用的PoV和相应术语完全是特定于应用程序的。
作为一个例子，考虑当你在当地杂货店买东西时会发生什么。从商店PoV，他们向您出售商品。从您的PoV，作为客户，您购买商品。如果您正在实施销售点终端的应用程序，您将对客户，销售，产品，折扣等概念进行建模。相反，如果您正在开发简单的iOS应用程序来跟踪费用，那么您将进行建模收入，费用（可能是购买），地方（可能是杂货店）等概念。没有必要在这个应用程序的上下文中将这样的概念建模为Customer，因为只有一个Customer - 一个当前用户，你。但是，在PoS终端应用程序的环境中建模这样的客户概念是完全可以的，这可能需要应用折扣或发送营销促销。
模型，其粒度和相应的术语将与正在开发的应用程序的观点和需求相匹配。