贫血领域模型或“逻辑放在哪里”

Question

这是“分析瘫痪”似乎已经发生的场景之一，所以请提出建议！

该项目

一个相当简单的汽车产品列表，其中包括零件参考、适合哪些车辆等详细信息。

前端是一个 asp.net MVC 应用程序。

后端是 SQL，使用 Subsonic 将产品投影到域对象中。

功能

我们的屏幕之一是产品详细信息屏幕。 ASP.NET MVC 控制器调用产品存储库来检索产品详细信息，并将这些详细信息（通过某些自动映射到 viewModel）返回到视图。

现在最致命的细节是我们有两个或三个进入网站的渠道，根据渠道的不同，用户需要看到不同的零件号。

举例来说，如果是零售渠道，则零件编号与数据库中的编号相同，但如果用户通过贸易渠道访问该网站，则零件参考的开头将被替换为替代编号。

例如，如果通过贸易渠道查看，0900876 就会变成 1700876。

我正在努力决定在哪里封装有关零件参考（以及可能改变的其他细节）的“渠道规则”。

我已经考虑过这些替代方案。

将逻辑直接写入域对象

在Product类上，我们可以有一个方法/属性来获取翻译后的部件引用。

public string TranslatedPartRef()
    {
        if (this.Channel == "Trade")
        {
            return PartRef.Replace("0900", "1700");
        }
        else
        {
            return PartRef;
        }
    }      

在这种情况下，产品实例必须了解通道，这对我来说似乎是错误的。

将逻辑封装在另一个对象中

我们可以编写一个类来处理这部分引用转换，或者创建一个包含此逻辑的 Channel 类。

但我不明白的是如何协调这两个类。

如果控制器调用存储库来检索产品，那么它是否应该找出使用的通道并翻译零件参考？如果是这样，我该如何将产品及其翻译后的零件参考发送回视图？

还值得注意的是，这部分参考也必须显示在搜索结果和其他场景中，因此我认为它需要整齐地包含在域中的某个位置。

Answer 1

我不是 C# 人员，但我想我会用 Java 中的装饰器来解决这个问题。

假设您有一个产品接口，那么您可以创建一个装饰器来管理部件号问题。

class Product implements IProduct {
    public String getProductCode();
    // etc
}

class ProductChannelDecorator implements IProduct
{
    // constructor, like this in C#?
    public ProductChannelDecorator(IProduct product, Channel channel) { 
        this.product = product;
        this.channel = channel;
    }
    public String getProductCode() {
        switch (this.channel) {
            case Channel.RETAIL:
                return this.decorated.getProductCode();
            case Channel.TRADE:
                return retailToTradeTransformer(this.product.getProductCode());
            // etc
        }
    }
    // etc
}

Answer 2

您需要问自己的第一个问题是 Channel 的概念是否是领域概念。您的问题似乎表明事实并非如此，但另一方面，我认为这听起来也不是特定于应用程序的。

您可能会问的另一个问题是：如果将来我需要在此域模型之上构建另一个应用程序（例如 Web 服务或富客户端），我是否仍然需要处理以下概念：渠道？

我的猜测是答案可能是是。

据我了解您的问题，频道以某种方式与请求上下文相关。也许这确实是用户的一个属性。或者也许 in 是应用程序配置本身的一个属性。

无论如何，我都会认真思考它是否真的不是一个领域概念。如果是，那么它可以很好地属于域对象。

如果没有，ptomli 建议的装饰器实现听起来是一个不错的方法。

Answer 3

零件号会有多少种不同的变体。如果只是贸易与零售，我很想简单地将两个数字都放在 Product 对象中，并让 UI 决定显示哪个。当对产品进行操作时，身份可以是“类型{贸易，零售}，数字”。

对于模式灵活的东西，我认为你的频道想法很好。但如果它有双向责任，将零售与贸易进行映射，这似乎会起作用。 Channel 对象可以被视为一个适配器，能够进行其他转换和丰富。

作为一个实现，我将为每个 Channel 创建一个单独的 Channel 对象，试图避免 case 语句和 if else else 逻辑。对于零售业，渠道对象可以是一个 NOOP 对象，对于贸易业，它可以进行映射。工厂可以创建适当的 Channel 对象。

Answer 4

如果零件编号映射可能发生变化怎么办？现在它是一个会发生变化的前缀，但是您是否还需要满足其他类型的变化？也许您不需要这个，但是：

在业务层面，您说产品可以有不同的部件号，具体取决于渠道（这毕竟是一个基本的业务概念）。因此，这表明在数据库级别，某处可能存在一个 PartNumber 表，其中包含 ProductId、ChannelId 和 PartNumber 列。这肯定会涵盖随着时间的推移出现更多渠道的情况（今天是零售或贸易，明天他们可能会添加网络、邮购等。可以想象，所有这些都可能需要不同的部件号）。

在对象级别，这映射到具有 Dictionary 的 Product 实例，可用于在给定 Channel< 的情况下获取适当的部件号/代码>。

Answer 5

现在最致命的细节是我们有两个或三个进入网站的渠道，根据渠道的不同，用户需要看到不同的部件号。

一个简单的解决方案：

public interface IChannel
    function GetNumber(Part as IPart) as String
end interface

没有装饰器，没有开关，没有控制反转。

每次您需要特定渠道的零件号时，您都可以调用此方法。

dim Channel as IChannel = ...
dim Part as IPart = ...
dim PartNumber = Channel.GetNumber(Part)

每次您需要不同的零件编号计算方法时，您只需实现此接口即可。

public class TradeChannel
    implements IChannel

    public function GetNumber(Part as IPart) as String implements IChannel.GetNumber
        return Part.Number.Replace("0900", "1700")
    end function
end class