架构领域模型和视图模型 [英] Architecture Domain Model and View Model

查看:68
本文介绍了架构领域模型和视图模型的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在尝试通过Spring Boot和Domain Driven Design来构建应用程序.我对域模型(与表DB的字段匹配)和视图模型(响应API)有疑问.

域模型:

EX:类名称

  @Getter@NoArgsConstructor@AllArgsConstructor班级名称 {字符串值;} 

类别产品

  @Getter@NoArgsConstructor@AllArgsConstructor类别产品{名字} 

ViewModel:

  @Data@NoArgsConstructor@AllArgsConstructor类ProductView {//int prodId;字符串prodName;} 

按类产品选择数据数据库,按类 ProductView 构建Response API.当从DomainModel转换为ViewModel或反之时,我为此在 ProductView 中编写了静态方法.它将变为:

  @Data@NoArgsConstructor@AllArgsConstructor类ProductView {//int prodId;字符串prodName;(产品prod)的public static ProductView {字符串productName = prod.getName().getValue();返回新的ProductView(productName)}} 

效果很好,但是当数据更多时.我认为需要将 CommonConvert DomainModel 转换为 ViewModel ,反之亦然.

我有一个使用 Mapstruct 库的解决方案.但是Mapstruct仅支持转换相同类型的字段(String和String,例如ex).编写CommonConvert的最佳解决方案是什么?

解决方案

我的建议: 请勿查询域模型并将其转换为视图模型以供阅读..>

域模型类(例如聚合)用于表示业务数据和行为,目的是在创建或更改此类业务实体时遵守业务不变式.

要从持久性数据中构建视图模型,您可以-我认为您应该- 绕过域模型 .您可以根据需要从数据库中安全地读取数据,而无需通过域存储库.

这没关系,因为您不能仅通过读取数据来违反业务规则.要写入数据,请通过域存储库和聚合.

对于您而言,您当然可以通过设计那些类以完全符合您的查看要求来使用通过JPA批注使用的视图模型实体.请记住,视图模型通常不与域模型相关联,因为它们可能只需要数据的一个子集或来自不同聚合的聚合数据.

另一个问题是,如果您需要查询许多对象以进行查看,则可以通过存储库查询完整的域聚合,从而迅速导致性能问题.由于此类聚合始终会从其子实体和值对象中加载所有数据,以允许对所有不变量执行业务逻辑,因此最终您将执行大量昂贵的查询,这些查询适合一次加载单个聚合,但一次却不能加载多个聚合.

因此,仅查询您需要查看的内容,您还可以解决此类性能问题.

遵循DDD时,通常应仅在业务交易中创建或更改一个聚合.因此,域模型不适合查询优化,但适合在写入业务数据时保持业务不变.

视图模型和相应的查询已针对读取进行了优化,并收集了所需的所有数据.

I am trying to build application by spring boot and Domain Driven Design. I have a problem about Domain model (match with fields of table DB) and View Model (response API).

Domain Model:

EX: class Name

@Getter 
@NoArgsConstructor
@AllArgsConstructor
class Name {
  String value;
}

class Product

@Getter 
@NoArgsConstructor
@AllArgsConstructor
class Product{
  Name name;
}

ViewModel:

@Data
@NoArgsConstructor
@AllArgsConstructor
class ProductView {
  //int prodId;
  String prodName;
}

Select data DB by class Product, builder to Response API by class ProductView. When that convert from DomainModel to ViewModel or vice versa, I written static method in ProductView for that. It will become:

@Data
@NoArgsConstructor
@AllArgsConstructor
class ProductView {
  //int prodId;
  String prodName;
  public static ProductView of(Product prod) {
    String productName = prod.getName().getValue();
    return new ProductView(productName)
  }
}

It works well, but when the data becomes more. I think need that as CommonConvert from DomainModel to ViewModel and vice versa.

I have a solution use Mapstruct library. But Mapstruct only support to convert field same type(String with String, ex). What is the best solution for writting CommonConvert?

解决方案

My advice: do not query domain models and translate them to view models for reading.

Domain model classes (e.g. aggregates) are used to represent business data and behaviour with the to purpose to adhere to business invariants when creating or changing such business entities.

For building your view models from your persistent data you can - and in my opinion you should - bypass the domain model. You can safely read the data from your database as you need it without going through domain repositories.

This is okay because you can't violate business rules by just reading data. For writing data go through domain repositories and aggregates.

In your case you can of course use view model entities using JPA annotations by designing those classes to exactly fit your viewing requirements. Keep in mind that view models often don't correlate to domain models as they might only need a subset of the data or aggregate data from different aggregates.

Another catch is that if you need to query many objects for viewing can quickly cause performance issues if you query full domain aggregates via repositories. As such aggregates always load all data from it's child entities and value objects as well to allow for performing business logic with all invariants you would end up performing lots of expensive queries which are suited for loading a single aggregate but not many of them at once.

So by querying only what you need for viewing you also address such performance issues.

When following DDD you should usually create or change only one aggregate within a business transaction. So domain models are not suited for query optimization but for keeping the business invariants in tact when writing business data.

View models and corresponding queries are optimized for reading and collecting all data required.

这篇关于架构领域模型和视图模型的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆