Re: Aggregates with dependencies

We prefer to inject in a domain service - DomainObjectContainer - into each
entity.  The user/security info is then accessible from that.

public class MyEntity {

    public void doStuff() {
        User user = container.getUser();
        ...
    }

    @Inject
    private DomainObjectContainer container;
}



On 15 February 2013 12:57, 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****
>
>
>
>
>
> ****
>
> ****
>
>
>
> 
>