在开发领域模型时，我可以看到考虑类/实体设计的两种主要方式。第一个假设程序是对现实世界中发生的事情的一种“模拟”。使用这种方法，您将拥有一个 Customer 类 - 例如 - 可能包含与 Customer 可以执行的操作相对应的方法。每当客户想做某事时，就会调用相应的方法。另一种方法是设计类，就好像它们暴露给用户一样，然后他/她有能力“直接”创建和使用对象，将程序视为用户现实的一种扩展。使用这种方法，客户类可能没有意义，因为客户已经“参与”了。我读过一些关于在方法级别添加安全性的文章，这似乎与这种方法一致，但我相信两者都在野外使用。你是怎么处理的？
谢谢。
【问题讨论】：
标签： oop architecture domain-driven-design
在开发领域模型时，您应该从不模拟现实世界中发生的事情。
真实世界太复杂了，您需要一个域模型来简化您的特定应用程序开发。我见过一些领域模型被定义为“非常灵活”（非常抽象）或“现实”（意味着过于详细和复杂而无法理解），所有这些都导致项目失败。
领域模型应仅包含领域专家与应用程序相关的知识（即始终他知识的一小部分），以使用他自己的语言的代码表示。它应该在有界上下文中进行拆分，从而进一步减少认知负荷。
如果他谈到“火车”，你可以在你的领域模型中有一个Train 类；如果他谈论策略，你可以在你的域模型中有一个 Strategy 类，但你不能在域中有一个 Strategy 类，因为你发现他称之为“玩家”的东西可以用 @987654321 实现@。
您可以必须模拟的是专家实际用来提供真实服务的“书面流程”。
对于剩下的问题，需要逐案评估，逐个申请。
例如，在我开发的金融应用程序中，不同的角色有时可以以不同的方式使用相同的概念。当我确定概念完全相同相同时，我使用bounded roles 来表达差异。但请注意，这永远不会发生在实体上，只是对对象和域服务进行赋值。如果您发现两个角色在谈论一个可识别的对象（也就是一个实体），那么您知道这两个角色唯一共享的就是对象的身份，但他们正在考虑不同的事情。
限界角色类似于您对假想的客户类所说的内容。
【讨论】：
如果我理解正确，您的问题主要是关于观点。答案是：您应该使用的 PoV 和相应的术语完全是特定于应用程序的。
举个例子，考虑一下您在当地杂货店买东西时会发生什么。他们从商店 PoV 向您销售商品。从您的 PoV 来看，作为客户，您正在购买商品。如果您正在为销售点终端实现应用程序，您将对客户、销售、产品、折扣等概念进行建模。相反，如果您正在开发简单的 iOS 应用程序来跟踪费用，您将进行建模收入、费用（可能是购买）、地点（可能是杂货店）等概念。在此应用程序的上下文中对诸如客户之类的概念进行建模是没有意义的，因为始终只有一个客户——当前用户，您。但是在 PoS 终端应用程序的上下文中，将诸如客户之类的概念建模是完全可以的，这可能需要它来应用折扣或发送营销促销活动。
模型、其粒度和相应的术语将与正在开发的应用程序的观点和需求相匹配。
【讨论】：