RE: Aggregates with dependencies

Technically speaking the problem is that ThreadStatic in a web application is a real pain. But I understood the concept and do not want to go OT.

From: [email protected] [mailto:[email protected]] On Behalf Of Willem van Gool
Sent: venerdì 15 febbraio 2013 14.06
To: [email protected]
Subject: Re: [domaindrivendesign] Aggregates with dependencies



If you'd implement it that way, I'd start with making it ThreadStatic. That makes it must more testable, and enables you to make the UserContext-setter internal (and thus not accessbile to your domain, increasing encapsulation). If you want, you can even create an associated UserContextScope-class that is responsible for initializing a certain UserContext that works something like this:

using (new UserContextScope(user))
{
    // UserContext.Current is now set to the specified user.
}

In your testcases, you can then create/dispose this scope in your setup/teardown methods of simply within a testmethod if the user must be altered for different cases.
On Fri, Feb 15, 2013 at 1:57 PM, Mauro Servienti <[email protected]<mailto:[email protected]>> wrote:

That is an option, but I hate the fact that it is "static" and thus hard to test.

.m

From: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Willem van Gool
Sent: venerdì 15 febbraio 2013 13.55

To: [email protected]<mailto:[email protected]>
Subject: Re: [domaindrivendesign] Aggregates with dependencies


Perhaps, assuming your User-entity represents something different than the current principal of your Thread, you could create your own UserContext in the command pipeline and then access UserContext.Current whereever you need it. That way, you can access it everywhere and keep your aggregates/domain model clean...would that be an option?
On Fri, Feb 15, 2013 at 1:35 PM, Mauro Servienti <[email protected]<mailto:[email protected]>> wrote:


I have something like:

storeAggregate.Dosomething();

And I do *not* want to have:

storeAggregate.Dosomething( User onBehalfOf );

.m

-----Original Message-----
From: [email protected]<mailto:domaindrivendesign%40yahoogroups.com> [mailto:[email protected]<mailto:domaindrivendesign%40yahoogroups.com>] On Behalf Of Willem van Gool
Sent: venerdì 15 febbraio 2013 08.24
To: [email protected]<mailto:domaindrivendesign%40yahoogroups.com>
Subject: Re: [domaindrivendesign] Aggregates with dependencies
Regarding your question, if an aggregat itself can depend on a service, id say no. It sounds like you're accessong the service in the wrong place. If you require realtime info from an external service for dag command, consider placing this logic in your handlers or as a behavior on your handlers and then forward this info to your aggregate where appropriate.

On 2/15/13, Mauro Servienti [email protected]<mailto:mauro%40topics.it>> wrote:
> Hi all,
>
> In our domain, financial but does not really care for the topic of the
> question, each aggregate raises a lot of events one of the key
> information that the event must carry with it is the user, the
> application user, that it currently managing the aggregate.
> We have a security service that knows who the user is and is the only
> source of truth we can rely on.
>
> Is it fine, from a ddd perspective, that an aggregate depends on a service?
>
> If not, how would you solve this scenario?
>
> .m
>
> Sent from my Yellow Lumia 920
>
------------------------------------

Yahoo! Groups Links