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
@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.
The text was updated successfully, but these errors were encountered:
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 ***@***.***> 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
<#34>, or mute the
thread
<https://github.com/notifications/unsubscribe-auth/AAGYMg61jCfr6Oj8cTiJaSTCkDtc4gKjks5sI-mngaJpZM4OJrla>
.
@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.
The text was updated successfully, but these errors were encountered: