【问题标题】:Passing current service object to domain will be a anti pattern for DDD?将当前服务对象传递给域将是 DDD 的反模式?
【发布时间】:2020-03-10 16:41:53
【问题描述】:

我有服务从存储库获取域并将其自己的实例传递给域以获得一些外部依赖。能不能变成反模式? RichDomainModel 建议根据需要将依赖传递给域,但是我担心这是否可以称为循环依赖并成为反模式?

class Order
{
  private $currencyVal;

  public function __construct()
  {

  }

  public function processBusinessLogic($arg1, $arg2)
  {
      // do some business logic operation on $arg1, $arg2 & $this->currencyVal
  }

  public function populateExternalValue(OrderService $service)
  {
    $this->currencyVal = $service->getCurrencyValue($this);
  }
}


OrderService 
{
  private $orderRepository;
  private $externalServiceClient;

  public function __construct(OrderRepository $orderRepository, Client $externalServiceClient)
  {
    $this->orderRepository = $orderRepository;
    $this->externalServiceClient = $externalServiceClient;
  }

  public function processDomain(Request $request)
  {
     $order = $this->orderRepository->findById($request->orderId);
     $order->populateExternalValue($this);
     $order->processBusinessLogic($request->arg1, $request->arg2);
     $this->orderRepository->save($order);
  }

  public function getCurrencyValue(Order $order) 
  { 
    return $this->externalServiceClient->getValue($order->currency)
  }
}

或者我可以使用这样的东西,但这会导致AnemicDomainModel

$order->setCurrencyValue($this->getCurrencyValue($order));

想法?

【问题讨论】:

    标签: design-patterns domain-driven-design anti-patterns


    【解决方案1】:
    1. 这绝对是一种循环依赖,这是一种反模式。
    2. 如果你想丰富领域模型,围绕$currencyVal 的逻辑应该从OrderService 移出到Order
    3. 由于逻辑依赖于$externalServiceClient,因此该客户端也将移至Order
    4. 请注意,anemic domain model 是 OOP 反模式;但你不必做 OOP。如果您有一个富域,那么富域模型是有意义的。对于逻辑很少的基本 CRUD 应用程序,它可能会过度设计。

    【讨论】:

    • 这是初始阶段,我在 Order 域中有一定程度的复杂性,这将随着时间的推移而增加,这就是我想要拥有丰富的域模型的原因。我想知道这是否是循环依赖和反模式我怎样才能摆脱它保持域的丰富?
    猜你喜欢
    • 2013-03-08
    • 1970-01-01
    • 2017-03-05
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2013-08-17
    • 1970-01-01
    相关资源
    最近更新 更多