域对象与表示模型无关!
使用领域驱动设计,您不必担心数据的显示方式和持久化方式。您唯一需要关注的是为您的业务建模。
此外,将您的业务模型暴露给前端用户并不是最佳实践。他们不必知道您的业务是如何运作的,您的业务规则是什么或与业务相关的任何事情。
这就是 ViewModel 或 DTO 的用途。这些是表示层实体,旨在通过任何类型的 Web 服务显示或公开。
由于其他原因,让您的数据库模型看起来像您的业务模型并不是一个好的选择。数据库引擎将不得不处理其他问题,这些问题将导致您组织数据的存储方式与您设计域的方式不同。
关于 Session,尽量保持轻量。正如@MikeSW 所说:
Session 不是 Cache
假设您想将每个实体存储在 Session 中。它可能很容易达到大约 250kb。乍一看可能并不大,但是如果您的服务器被 10,000 个不同的用户访问怎么办?您的会话大小将急剧增长到 2,3Gb!仅用于会话数据!这显然会导致性能问题。
编辑 --- 对于您的新问题
因此,在实践中,如果我使用 DDD,我仍然必须创建一个浅(贫血)对象模型或 DTO,以在表示层和服务(业务)层之间共享数据。
好吧,假设您必须构建一个 MVC 项目。
您Controllers
将处理请求,他们将调用 aModelBuilder
来获得权利Model
并将其返回给View
.
这取决于ModelBuilder
您的Domain Services
. 这些服务将返回您必须映射到View Model
.
如果您要公开一些 Web 服务,这将以某种方式起作用。
Web 服务的合同是Interfaces
. 这些契约定义了 Web 服务公开的方法和被操作的对象 (DTO)。这取决于实现合约接口的类来调用你的Domain Services
. 这些服务将返回您必须映射到的域对象DTO
。
如果有任何好的参考应用程序或文章谈论类似的架构
DDD 不是任何技术或架构。这都是关于:
定义普遍存在的语言意味着领域模型应该形成由领域专家给出的用于描述系统需求的通用语言,该语言同样适用于业务用户或赞助商以及软件开发人员。
如果您想知道如何设计您的应用程序,请查看与 Java n 层架构相关的 SO Questions 和文章。