search

jbogard / ContosoUniversity

Contoso University sample re-done the way I would build it
Apache License 2.0
392 stars 131 forks source link

Should features own the domain model as well? #34

Open ngbrown opened 7 years ago

ngbrown commented 7 years ago

@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.

jbogard commented 7 years ago

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 notifications@github.com 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 .