Re: Is IoC containers harmful for DDD?

I'd be happy for you to put up some examples of dealing with application
services/command handlers to illustrate the points you make. I dislike
talking in hypotheticals, code is much easier.

Cheers,

Greg

On Tue, Dec 2, 2014 at 5:42 AM, Rikard Pavelic [email protected]
[domaindrivendesign] <[email protected]> wrote:

>
>
> On Tue, 2 Dec 2014 05:24:23 -0800
> "Greg Young [email protected] [domaindrivendesign]"
> <[email protected]> wrote:
>
> > How does a plugin architecture interfere with using a bootstrap
> > method? It is quite common to do both (even compiling the bootstrap
> > code at start). This has been a common practice in functional
> > languages for decades.
> >
>
> Bootstrap without the container in non-trivial scenarios results in
> poor main container.
> You said one of the examples, you want to inject transaction in
> repository, so return Func instead.
> Which is a good solution if thats the only use case - transaction per
> session.
>
> But whenever I see such examples (Cake in Scala) I'm not sure that
> people bashing containers used it for non-trivial examples.
> In their defense, JVM containers don't support many of useful scenarios
> (like nesting contexts) so I can see from where they are coming from.
>
> For example, your example for app service where you converted class to
> a function by providing it by explicit repository instance is not
> really something you can get away in plugin systems. For couple of
> reasons:
>
> 1) You don't really know dependencies of that class - you can use
> reflection to look them up - but again going into poor man Ioc land
> 2) You don't know context for that object in advance - thus, delegating
> work of injecting correct context to someone else (whether it's global
> context, thread context, session context, using context) simplifies
> domain code a lot (not going into discussion about other people's
> code). I've also seen systems which assume there are only couple of
> contexts: global and thread, which fail to work in event style way,
> since context is neither global, nor thread.
>
> But then, I don't want to argue about IoC, especially since you said
> they have their place and uses, just saying I find you example of
> replacing IoC bootstrap with manual configuration misleading.
>
> Regards,
> Rikard
>
> --
> Rikard Pavelic
> https://dsl-platform.com/
> http://templater.info/
>  
>



-- 
Studying for the Turing test