Re: Aggregates with dependencies

This sounds an awful lot the discussion of "how do I handle session for
hibernate"

On Fri, Feb 15, 2013 at 3:55 PM, Mauro Servienti <[email protected]> wrote:

> **
>
>
>  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]> 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]] *On Behalf Of *Willem van Gool
> *Sent:* venerdì 15 febbraio 2013 13.55****
>
>
> *To:* [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]> 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:
> [email protected]] On Behalf Of Willem van Gool
> Sent: venerdì 15 febbraio 2013 08.24
> To: [email protected]
> 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]> 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****
>
>
>
>
> ****
>
>
>
>
>
> ****
>
> ****
>
>   
>



-- 
Le doute n'est pas une condition agréable, mais la certitude est absurde.