Re: Is IoC containers harmful for DDD?

On Tue, 02 Dec 2014 13:35:29 +0100
"Thomas Presthus [email protected] [domaindrivendesign]"
<[email protected]> wrote:

> > Thus I dislike some of the preachings of DDD practitioners (I can
> > explain more if someone is interested) which are preferring closed
> > systems instead of open ones.
> 
> 
> I'd like to hear more of your view on this. Personally I don't see
> why DDD tactics should prevent you from creating plugin based
> architectures. Plugins sounds like good candidates for boundaries.
> 

I think it boils down to what it means domain boundary to people.
When you see DDD explained, you usually get that:

1) anemic model is anti-pattern - since you can't really control
behavior of an aggregate
2) logic must be implemented inside domain object, so it's contained in
one placed and not spread through transaction/service scripts
3) database is not part of your domain, but an external system and you
should threat it as such
4) you don't need frameworks, you can reimplement what you need in a few
lines of code
5) UI is not part of your domain, but a mere presentation
6) if you have too many joins, you have not modeled your domain
properly
and few others, but let's stick with that for now...

So, I find most of those advices wrong in certain contexts and see them
turn off people from DDD. So let me try and explain why I think they
are wrong in some scenarios:

1) if you consider class as aggregate boundary and want to restrict
other developers accessing that class changing it in inappropriate
ways, you hide property access from it and expose intention
revealing methods for interaction. Thats basic DDD. But if consumers of
your aggregate don't access the class directly, but through some layer
(such as http), then it becomes less important to hide members in it.
If you don't allow for CUD on it, but only allow domain events
(messages) modifying it's state, it becomes much less important to
restrict how that class is modified. This enables you to open up your
class so that behavior is not implemented inside it (although it can be
and in .NET with extension methods it looks like they are) and you end
up with a system where you can append behavior to that aggregate without
modifying it's code. Those systems are not that much different from
other CRUD + services systems, but they certainly benefit from other
DDD concepts.
2) saying that complex logic needs to be implemented
inside aggregate and seeing people struggle with dependencies for that
method really shows the difficulties of trying to jam complex service
behavior into an aggregate. Most common use case is that rarely
aggregate is changed in isolation. While you'll hear that it's
exception to modify multiple aggregates inside a transaction, it's not
really an exception (even with good domain model).
3) going back to the first example where you've exposed domain though
the http layer, one could argue that there is not much difference
between your objects, logic and the database. They are all behind some
other layer and can be changed freely. It's not really important
whether your logic lives in OO code, some big function or DB stored
procedure as long as implementation doesn't leak beyond your http layer.
4) while most frameworks are bad, implementing your own framework is
even worse. And it's certainly not true that you can reimplement
features such as LINQ on top of ORDBMS with a few lines of code. Let's
not even go into serialization libraries/frameworks or other
infrastructure concerns. I've personally experienced deep stack traces
from various libraries, but the alternative is even worse.
5) domain events often come from UI. And most internal apps are just UI
access to aggregates (sometimes a subset of it and
sometimes spanning several aggregates and aggregate types at once).
Not considering those requirements as a part of the domain (where UI is
the sole interaction point with the domain) is really strange.
6) ERP systems have a tendency to grow really big (even small ones).
And when you want to do analysis of such systems you end up with really
big joins. Saying that with DDD you will get rid of those joins since
you will not need them due to better domain model is not really
true.

Enough rant for today ;)

Regards,
Rikard

-- 
Rikard Pavelic
https://dsl-platform.com/
http://templater.info/


------------------------------------
Posted by: Rikard Pavelic <[email protected]>
------------------------------------


------------------------------------

Yahoo Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/domaindrivendesign/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/domaindrivendesign/join
    (Yahoo! ID required)

<*> To change settings via email:
    [email protected] 
    [email protected]

<*> To unsubscribe from this group, send an email to:
    [email protected]

<*> Your use of Yahoo Groups is subject to:
    https://info.yahoo.com/legal/us/yahoo/utos/terms/