You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The implementation lives inside the infrastructure layer.
Since the Extractor Service only gets the interface type hinted I think it is valid to see it as a Domain Service.
Unfort. this is quite hard to unit test. It would require mocking or a InMemoryTermRepository with same fake data.
It also looks like it is violating the single-responsibility principle (SRP).
This is much easier to test. Though a developer could easily use this code to manipulate the Extractor result by freely passing any Terms as argument. But I guess the developer should not be "the enemy".
Which approach do you prefer? Any exceptions to this or improvements?
Thank you for your feedback.
The text was updated successfully, but these errors were encountered:
I would use the first implementation, I don't think that it (the first example implementation) breaks the SRP principle, since it uses domain components (repository with domain service), yeah using test doubles for testing is fine, integration testing will cover the caveats of unit tests.
I guess even with the second implementation you have to make test double for the repository.
Came from:
I have a service that extracts the MIN and MAX date of a period. This is the original INSIDE approach #1
Domain Service
Application Service (Command Handler)
The domain layer always holds an interface for the
TermRepository
:The implementation lives inside the infrastructure layer.
Since the Extractor Service only gets the interface type hinted I think it is valid to see it as a Domain Service.
Unfort. this is quite hard to unit test. It would require mocking or a
InMemoryTermRepository
with same fake data.It also looks like it is violating the single-responsibility principle (SRP).
This is my OUTSIDE approach #2:
Domain Service
Application Service (Command Handler)
This is much easier to test. Though a developer could easily use this code to manipulate the Extractor result by freely passing any
Terms
as argument. But I guess the developer should not be "the enemy".Which approach do you prefer? Any exceptions to this or improvements?
Thank you for your feedback.
The text was updated successfully, but these errors were encountered: