這是將領域知識泄漏到服務層嗎？

Question

目前，我的服務層處理加載負責對某些域事件做出反應的聚合根。 這涉及使用一些領域知識（誰應該/何時做出反應）調用持久層來過濾和加載負責的聚合根。 這是否被認為是領域知識泄漏以及如何防止它？

謝謝！

Answer 1

我的服務層處理加載負責對某些域事件做出反應的聚合根。 這涉及使用一些領域知識（誰應該/何時做出反應）調用持久層來過濾和加載負責的聚合根。

如果您願意將“應用層”替換為“服務層”，我想您會發現這與 Eric Evans 在原始領域驅動設計書中描述的模式非常匹配。

該層保持薄。 它不包含業務規則或知識，而只是協調任務並將工作委托給下一層領域對象的協作。 它沒有反映業務情況的 state，但它可以具有反映用戶或程序的任務進度的 state。

示例貨運應用程序（Eric Evans 和 Citerus 之間的合作）展示了我在與其他 DDD 從業者討論設計時經常看到的模式。 我認為您正在談論的代碼在這里： https://github.com/citrus/dddsample-core/blob/master/src/main/java/se/citrus/dddsample/application/impl/BookingServiceImpl.java

  public void assignCargoToRoute(final Itinerary itinerary, final TrackingId trackingId) {
    final Cargo cargo = cargoRepository.find(trackingId);
    if (cargo == null) {
      throw new IllegalArgumentException("Can't assign itinerary to non-existing cargo " + trackingId);
    }

    cargo.assignToRoute(itinerary);
    cargoRepository.store(cargo);

    logger.info("Assigned cargo " + trackingId + " to new route");
  }

在這種情況下， Itinerary和TrackingId是值對象 - 定義在域層中，但這些實例實際上是在 web/表示層中構造的，並傳遞給負責協調的應用程序邏輯。

---

我想知道如何 go 關於加載/過濾負責任的聚合根而不會將領域知識泄漏到服務層？ 例如，使用有關誰/何時應該處理域事件的一些業務知識過濾聚合根。

我使用的啟發式方法是我們希望將計算/邏輯與信息檢索分開。 因此，如果確定要加載的正確聚合取決於用戶提交的表單數據、稅表以及 CEO 上周在機場進行的對話，那么我們更喜歡這樣的設計

aggregateId = computeTheAggregateId(formData, taxTable, ceo.conversation())

aggregate = repository.get(aggregateId)
aggregate.doSomethingCool(formData)

computeTheAggregateId屬於application還是domain ？ 在摘要中，它的重要性並不明顯。 正確的答案可能取決於它更改的頻率，或者同時更改的代碼。

歸根結底：這是一種模式語言——如果模式在你所處的上下文中“不起作用”，那么你應該有很好的判斷力不使用它。