Nice article, thanks! Term/comparison "magnifying lens" - 100% match :)
About IClock interface/approach: maybe it is better to pass current date/time as a parameter into domain service?
In this case we will have less dependencies in domain service. As a result - it should be easier to test + we will have more explicit method's signature/contract.
My thinking was, `DateTime` type isn't part of the contract really of that particular method that creates the customer, it's one additional thing that the method is doing (setting the creation time of an entity before calling the repository method).
One could argue that this could be done outside the domain service completely since it's a violation of the (SRP) principle (hence the beauty of Unit Test!), for example we could use some kind of interceptor service that before executing the underlying repository method it sets those auditing fields in the entities or other way to handle that cross-cutting concern.
One example I could think of is that when we do a filtering by default by the current date time (GetCustomersThatCreatedToday) for some reason, or getting customers that are updated today, or even in case of soft delete, get all customers that has been deleted today, there I could see definitely having the `DateTime` value as part of the contract of the public interface is more beautiful and explicit design.
But in terms of simplicity, one could say it's definitely to just pass the `DateTime` value to the method as a parameter
Nice article, thanks! Term/comparison "magnifying lens" - 100% match :)
About IClock interface/approach: maybe it is better to pass current date/time as a parameter into domain service?
In this case we will have less dependencies in domain service. As a result - it should be easier to test + we will have more explicit method's signature/contract.
That's definitely an interesting thought Andrei!
My thinking was, `DateTime` type isn't part of the contract really of that particular method that creates the customer, it's one additional thing that the method is doing (setting the creation time of an entity before calling the repository method).
One could argue that this could be done outside the domain service completely since it's a violation of the (SRP) principle (hence the beauty of Unit Test!), for example we could use some kind of interceptor service that before executing the underlying repository method it sets those auditing fields in the entities or other way to handle that cross-cutting concern.
One example I could think of is that when we do a filtering by default by the current date time (GetCustomersThatCreatedToday) for some reason, or getting customers that are updated today, or even in case of soft delete, get all customers that has been deleted today, there I could see definitely having the `DateTime` value as part of the contract of the public interface is more beautiful and explicit design.
But in terms of simplicity, one could say it's definitely to just pass the `DateTime` value to the method as a parameter