非数据类（不代表数据库中的任何内容）是否仍被视为应用程序域模型的一部分？您会将它们与您的 Linq2Sql 域模型或其他地方放在一起吗？
编辑：关于类的信息：例如，我有一个在某些情况下实例化的“StatusMessage”类，可能会被丢弃或显示给用户。它与数据库中的数据无关（既不检索也不存储）。另一个例子是“邀请”类。我网站上的用户可以互相“邀请”，如果他们这样做，则会创建一个 Invitation 类，该类将加密一些信息，然后输出一个用户可以提供给其他人的链接。我有> 25这些课程。它们不是用于数据传输的，它们是做实际工作的，但它们与数据库无关，我不会说它们都是“帮手”？！……
域模型是与域相关的数据。它可以来自任何来源，可以是一种方式（例如，仅计算和持久化，从不回读）。数据库只是一种域数据持久化策略。
所以是的，来自不同地方的数据可能是域模型的一部分。
就我个人而言，我认为消息更像是一个视图模型实体，而指示特定消息需求的状态可能在域模型中。在邀请的情况下，我会说消息流向服务并因此成为域数据 - 最终传递给并且我想成为与其他用户相关的域数据（并且说使用其他视图模型显示） .
这取决于。
如果这些类代表来自不同表的数据、处理数据、做出决策和协调操作的组合，我会将它们视为业务级实体并将它们保留在业务层中。
如果这些是某种帮助者，那将取决于。
补充：在阅读了你关于这些类的额外信息之后，我认为它们中的许多都应该在你的业务逻辑中占有一席之地。您可能希望在域模型和业务逻辑之间划清界限。我想您认为您的域模型仅包含数据库映射类，这很好。但也有业务规则、接受用户输入、处理它、做出决定并调用必要操作来执行它们的工作类。这些可以包括对数据库进行 CRUD、发送电子邮件通知、启动调度程序任务、通知其他服务等。对于许多操作，它们的结果只会在数据库中远程反映，某些值可能会更改，但不像完整的业务对象状态那样直接到数据库。因此，将它们放在一个专用层中是有意义的。
另一种选择是将这些类的逻辑放入存储过程中，从而将其保存在数据库中。不适合那里的东西可能会被归为帮手。
使用“StatusMessage”，可能不需要为此设置单独的类。消息属于视图级别。一个类可以决定显示哪条消息，但真正的显示工作将在更靠近 UI 的地方进行。