OOP (哲学)

Question

在开发领域模型时，我可以看到关于类/实体设计的两种主要方式。第一种假设是，程序是对现实世界中发生的事情的一种“模拟”。使用这种方法，您将拥有一个Customer类-for示例-可能具有与Customer可以执行的操作相对应的方法。每当客户想做某件事时，相应的方法就会被调用。另一种方法是设计类，就好像它们向用户公开一样，然后他/她就有能力“直接”创建和使用对象，将程序视为用户现实的一种扩展。使用这种方法，客户类可能没有意义，因为客户已经“参与”了。我读过一些文章，讨论在方法级别添加安全性，这似乎与这种方法一致，但我相信两者都被广泛使用。你是怎么处理这个问题的？

谢谢。

Answer 1

在开发领域模型时，您应该永远不要模拟真实世界中发生的事情。

真实的世界太复杂了，您需要一个域模型来简化特定的应用程序开发。我已经看到一些领域模型被定义为“非常灵活”(非常抽象)或“现实”(这意味着太详细和复杂，难以理解)，所有这些都会导致项目失败。

领域模型应该只包含领域专家与应用程序相关的知识(即，总是他的知识的一小部分)，这些知识是使用他自己的语言的代码表达的。它应该在有界的上下文中进行拆分，从而进一步减少认知负荷。

如果 he 谈到“训练”，你可以在你的域模型中有一个Train类；如果他谈到策略，你可以在你的域模型中有一个Strategy类，但是你不能仅仅因为你发现他所谓的“玩家”可以用strategy pattern实现而在域中有一个Strategy类。

you 必须模拟的是专家实际用于提供真实世界服务的“纸质流程”。

对于问题的其余部分，需要逐个案例、逐个应用程序进行评估。

例如，在我开发的金融应用程序中，不同的角色有时可以以不同的方式使用相同的概念。当我确定这个概念与完全相同时，我会使用bounded roles来表示不同之处。但请注意，这永远不会发生在实体上，只会对对象和域服务进行赋值。如果你发现两个角色在谈论一个可识别的对象(也就是一个实体)，你就会知道这两个角色唯一的共同点就是对象的身份，但是他们想的是不同的东西。

限定角色类似于您所说的关于您的假设客户类的内容。

Answer 2

如果我理解正确的话，你的问题主要是关于观点的。答案是:您应该使用的PoV和相应的术语完全是特定于应用程序的。

作为一个例子，考虑一下当你在当地的杂货店买东西时会发生什么。从商店PoV他们在卖东西给你。从你的PoV，作为一个顾客，你是在购买商品。如果您正在为销售点终端实现应用程序，则将对客户、销售、产品、折扣等概念进行建模。相反，如果您正在开发简单的iOS应用程序来跟踪费用，则将对收入、费用(可能是购买)、地点(可能是杂货店)等概念进行建模。在这个应用程序的上下文中建模客户这样的概念是没有意义的，因为总是只有一个客户-当前用户，你。但是，在PoS终端应用程序的上下文中，将这样的概念建模为客户是完全可以的，它可能需要应用折扣或发送营销促销。

模型、其粒度和相应的术语将与正在开发的应用程序的观点和需求相匹配。