大家好，那是我的第一篇文章，这是一个很重的文章（至少对我来说）。

我已经阅读了很长一段时间

所以我今天对此有一些淋浴的想法。
当然，这个想法远非结论性，我觉得这对一个真正的项目真的太重了。如果有人找到此页面，我会发表这篇文章，主要是为了备份。

，总而言之，我看到了很多关于将教义实体/文档作为汇总本身或制作包含学说实体的汇总的文章。和存储库来创建这些聚合。

这对我来说很好，并且主要与ODM一起工作，我肯定会以第一种方法作为我的首选，因为它比我的想法要简单。

，但我觉得将我们的“ datamodel”作为汇总不好，保持不屈服和域层过于束缚。

我的“想法”，终于！

所有这些都是背景故事，我的“想法”很简单...
使DataModel（学说实体/文档）的一部分是基础结构层的一部分，并将汇总的简单类从学说实体映射。

对于查询，我们将有这样的过程：
Controller> QueryHandler> AggregateRepositoryAbstractionService（尚未考虑名称）> Repository
Repository正在返回学说实体/文档
AggregateRepositoryAbstractionService正在调用存储库，并将这些实体/文档映射到所选的汇总并返回汇总

以这种方式，DataModels与Aggregate完全分开，您可以在不同上下文中轻松地制作不同的Aggregate。

让我们以Post和Comments的常见示例。
和不同的上下文：GetPostAndComments，GetPostOnly，GetComment等。
您可以制作多个汇总PostFullAggregate，PostOnlyAggregate，PostCommentAggregate等。
我认为您现在得到这个，PostFullAggregate（带有/posts/1 URL）会查询Post，每个CommentS，PostCommentAggregate（带有/posts/1/comments/1 url）只会查询帖子的评论。

关于文件结构，您可以拥有类似的东西

├── src
│   ├── Application
│   ├── ├── Query // contains the Query, QueryHandler, etc.
│   ├── ├── RepositoryAbstraction // not sure if this should be here though
│   ├── Domain
│   │   ├── Post
│   │   ├── ├── PostFullAggregate.php
│   │   ├── ├── PostCommentAggregate.php
│   ├── Infrastucture
│   ├── ├── DataModel
│   ├── ├── Mapping
│   ├── ├── Repository

就像我说的那样，开发比您可以在这里和那里找到的共同实现要重一些，因为您具有聚合物和datamodel和一个可选的repositoryabstraction。

希望有人会找到此页面，并会给我他对此的看法，也许我完全错了。

ps：本文真的很粗糙，我可以编辑一些东西。