建立与人际关系的实体的正确方法是什么

Question

我有一些工厂负责构建产品实体。要构建产品有必要从应与product关联的数据源检索所有实体。

class ProductFactory(
    private val productRepository: ProductRepository,
    private val shopRepository: ShopRepository,
    private val categoryRepository: CategoryRepository,
    private val tagRepository: TagRepository
) {
    fun build(action: CreateProductDTO): Product {
         val product = Product.Builder()
         val shop = shopRepository.findById(action.shopId)
         product.setShop(shop)

         val tags = tagRepository.findAllById(action.tags)
         product.setTags(tags)

         val category = categoryRepository.findById(action.categoryId)
         product.setTaxon(taxon)

         return productRepository.save(builder.build())
    }
}

我个人至少违反了界面隔离原则，因此我不喜欢上面的代码。 productFactory可以访问存储库的所有方法，但不应该这样做。

我想创建某种称为存储的DAL，可用于特定业务操作，例如产品创建。例如：

interface Storage {
    fun findShopById(id: Long): Optional<Shop>
    fun findCategoryById(id: Long): Optional<Category>
    fun findAllTagsById(ids: Iterable<Long>): List<Tag>
    fun save(product: Product)
}

有建议吗？

Answer 1

您要应用的界面隔离原则是一个好主意。它使测试变得更加容易，因为您只需要一个模拟，而不需要一堆模拟。

我将界面命名为客户端的客户端，例如productFactoryRepository。

您的productTrepository实现的代码似乎是我通常会在交互式中写的代码（又称用例）。库尔斯（Cource），您可以根据需要将其提取到自己的课程中。

但是，有一件事可能会破坏架构（如果我理解您的代码）。这是这个功能。

 fun build(action: CreateProductDTO): Product {

据我了解你。 ProductFactory是实体（或域）层的一部分。 createProductDto似乎属于控制器（Web或传输）层，因为DTO通常代表数据传输对象。

但这意味着您具有从实体层到传输层的依赖性，这破坏了干净体系结构的体系结构。

干净的体系结构建议将普通数据结构传递到inputport中。这些数据结构通常称为requestModel和exponsememodel。

Interactor应实现这样的输入端口：

interface CreateProductInputPort {
    fun createProduct(requestModel: CreateProductRequestModel, outputPort: CreateProductOutputPort)
}

requestModel可以是一个简单的数据

data class CreateProductRequestModel(val shopId: Int, val tags: Array<String>, val categoryId: Int)

，或者您可以声明接口

interface CreateProductRequestModel {
   fun getShopId(): Int
   fun getTags(): Array<String>
   fun getCategoryId(): Int
}

，然后让createProductdto实现它。

您应该将交互式（用例）与传输层分解以应用单个职责原则，因为除用例输入模型以外的其他原因，DTO会更改。

PS：我希望我写的Kotlin代码正确。我通常在Java中代码。

Answer 2

您正在混淆 Intantiation 和插入概念：

• insertion 是当您在系统中添加新实体时发生的逻辑操作，例如添加一个产品目录的新产品。
• Intantiation 是一个技术操作，当您想在内存中创建一个新对象时，例如将DTO转换为实体，或者您从数据库中检索现有产品时。

在DDD中，A Factory 是负责实体实例化的对象。实体插入是存储库的责任。在大多数情况下，您无需编写工厂，因为您可以编写一些简单的代码，例如product product = new Product（）;或使用一些映射库来投影数据持久性对象（DPO ）进入实体。

但是，有时候，对象实例化可能会成为一项复杂的任务，您可以编写工厂来考虑此代码并从不同类别重复使用。代替编写产品=新产品（）;而不是编写product product = productFactory.makeproduct（...）;和注入工厂之类的东西。

这意味着您的productFactory实际上应该是您的Builder类：

class ProductRepository(
    private val productFactory: ProductFactory,
    private val shopRepository: ShopRepository,
    private val categoryRepository: CategoryRepository,
    private val tagRepository: TagRepository
) {
    fun insert(action: CreateProductDTO): Product {
         val shop = shopRepository.findById(action.shopId)
         val tags = tagRepository.findAllById(action.tags)
         val category = categoryRepository.findById(action.categoryId)
         val product = productFactory.MakeProduct(shop, tags, category)
         product.Name = action.productName
         return this.save(product)
    }
}

Answer 3

遵循DDD教条，两个聚合物应使用ID互相转介，而不是在产品聚合中设置整个商店/标签/类别:)这就是为什么该代码对您感到奇怪的原因，破坏该规则完全使用了使用存储库的必要性。

我想，使用整个shop是由您使用的持久性技术驱动的。
您有兴趣在工厂中做的是检查具有该ID的商店是否真正存在。

应当处理查询（将服务传递）到您的productFactory，以便将其与shop> shop> shop的详细信息解耦，并且只能访问由您的暴露的API域（通过服务查询/命令）