search

mploed / ddd-with-spring

Code examples for my conference talk on implementing ddd with spring
Apache License 2.0
771 stars 198 forks source link

Scoring module breaks the hexagonal architecture's dependency rule #3

Closed JonasHavers closed 4 years ago

JonasHavers commented 6 years ago

Hi @mploed!

Thanks for creating this public example. I like the idea to use package-scoping to hide the aggregate's containing entities and value objects from the public, although this is quite different from the "usual" hexagonal package structure (e.g. in Vaughn Vernon's IDDD samples).

In your "scoring" module, repositories (e.g. ApplicantResultRepository, FinancialSituationResultRepository) are placed inside the "adapters-output" submodule. The submodule also includes projections like the ApplicantResultProjection which is used as a return type of the ApplicantResultRepository's methods. The ApplicantResultRepository as well as the ApplicantResultProjection is used in the ScoringApplicationService.

  1. This creates a dependency from the Application Layer (outwards) to the Driven (Output) Adapter which breaks the dependency rule that says that source code dependencies can only point inwards. Would you move the projections? They are a technical concern of the Output Adapter (which is clearly illustrated by JPA's @Entity, @Id... annotations), so I'd agree it they stay there. But that doesn't solve the issue. What's your opinion and idea on this? Would you agree that the domain part of the repository interface (= ApplicantResultRepository#save(ApplicantAggregate)) should belong to the domain model (which is currently separated into the "aggregates" and "sharedmodel" submodules)?

  2. Currently, the ScoringApplicationService is living inside the "adapters-input" submodule. I think it should be moved to the "application-services" submodule which is currently empty.

mploed commented 4 years ago

Thanks for raising this (and sorry for the late reply). This issue should was fixed a couple of months ago.