ContosoUniversity icon indicating copy to clipboard operation
ContosoUniversity copied to clipboard

Should features own the domain model as well?

Open ngbrown opened this issue 7 years ago • 1 comments

@jbogard, you've written that the domain model could receive a command for changes (and here), but I've not seen that combined with MediatR usage. In this project you use AutoMapper to apply the message externally per-property, and the models classes don't receive message objects through functions on them.

Does it make sense to be receiving the IAsyncRequest derived commands/requests in the domain model?

In my applications, I keep the domain models in a separate assembly so they can be shared with back-end asynchronous processes that don't run in the web context.

Should the non-web portion of the features (request, handler, response) live in the domain model assembly? Should there be domain model specific commands that are mapped to when needed from the IAsyncRequest commands after validation; keeping the features in the web project?

Thanks in advance.

ngbrown avatar Jun 29 '17 18:06 ngbrown

Yeah, you know, that does make sense in a lot of scenarios. And even having the messages/handlers pushed down into the domain, that's what we've done in many scenarios.

On Thu, Jun 29, 2017 at 1:15 PM, Nathan Brown [email protected] wrote:

@jbogard https://github.com/jbogard, you've written that the domain model could receive a command for changes https://lostechies.com/jimmybogard/2016/04/29/validation-inside-or-outside-entities/ (and here https://lostechies.com/jimmybogard/2010/03/31/strengthening-your-domain-avoiding-setters/), but I've not seen that combined with MediatR usage. In this project you use AutoMapper to apply the message externally per-property, and the models classes don't receive message objects through functions on them.

Does it make sense to be receiving the IAsyncRequest derived commands/requests in the domain model?

In my applications, I keep the domain models in a separate assembly so they can be shared with back-end asynchronous processes that don't run in the web context.

Should the non-web portion of the features (request, handler, response) live in the domain model assembly? Should there be domain model specific commands that are mapped to when needed from the IAsyncRequest commands after validation; keeping the features in the web project?

Thanks in advance.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/jbogard/ContosoUniversity/issues/34, or mute the thread https://github.com/notifications/unsubscribe-auth/AAGYMg61jCfr6Oj8cTiJaSTCkDtc4gKjks5sI-mngaJpZM4OJrla .

jbogard avatar Jun 29 '17 19:06 jbogard