如何设计实体（领域模型），您喜欢小还是大？
您好，我正在使用Spring和Mybatis创建一个简单的公开市场门户网站。该服务供媒体公司使用其自己的帐户撰写文章。 文章中可以有许多标签可供搜索。这些标记不是动态生成的，而是已经定义的。
因此，数据库具有这些表。
COMPANY (company_id, login_id, login_pw, ...) ARTICLE (article_id, title, content, author, ...) TAG (tag_id, tag_desc, ...) ARTICLE_TAG (article_id, press_id) relation of both article and tag (1:N)
它更复杂并且实际上具有更多的域，但是我总结了一些问题 我希望将其设计为易于扩展功能和域。
我在桌子上simplay设计了领域模型（实体）1：1匹配。 在研究了春季MVC之后。现在，我知道实体设计应该集中精力，不需要将实体与数据库数据模型进行匹配。
我知道只有Entity（域模型）才能访问db， 因此，我将实体复制到许多其他DTO（响应），这些DTO适合在服务层上查看。 我还修改了实体的DTO（请求）以访问（插入，更新）服务层上的数据库 （使用实体正确吗？）
我对如何在db中为1：N或N：M关系设计实体感到困惑。 我想在下面输入两种类型的实体
巨大的实体具有一些列表变量来保持1：N或N：M关系。 在实现具有几个字段（标题，create_dtm）的简单列表视图时 ，我们必须创建一个具有title和create_dtm变量的DTO。 在服务层中创建DTO时，几乎字段丢失。 它有一个重载，即使调用了简单的列表视图，该重载也会执行联接的查询。
我正在使用它。小实体几乎与表相同。如果某些视图呈现1：N或N：M关系。 我们必须创建DTO，该DTO具有用于1：N或N：M关系的列表变量。 因此在这种情况下，其他域映射器在服务层中被调用。 它有一个过载，可以多次执行不同的查询。
我正在使用小型实体。 它必须执行基于标签和其他文章字段的联合查询来进行搜索。 最后，我使映射器直接返回不是文章实体的ArticleSearchResponseDTO（response）。 我知道它破坏了纯建模，但是删除了多次执行不同查询以填充变量的重载。我不知道破坏模型的成本是多少。
我的问题是 您更喜欢大型实体还是小型实体？你为什么喜欢那个。 直接在映射器上返回ArticleSearchResponseDTO（response）有什么问题？