Re: Is IoC containers harmful for DDD?

>
> 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.


DDD is not for facilitating HTTP protocols. DDD is used to make it easy to
to implement changes to the domain in a fast peace, reacting to the changes
of the business, and for that you really need to have the behavior and data
combined in the same aggregate. For using HTTP you can have a services
layer (aka Application layer) that exposes services that know how to deal
properly with that protocol. Not sure why you say that you would need to
hide members (why should you?). You just need to make sure that those
members can't violate the internal state. In DDD it doesn't matter if the
client access the domain directly or not. If you use DDD is because you
really need it, otherwise don't use it. If you have a big solution you
wouldn't probably need to use DDD everywhere, only for specific parts, the
ones that differentiate your business from others.

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.


An aggregate is not a service and dependencies are no different in DDD than
anywhere else, you just have to deal with them using an appropriate pattern.

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).


If you have to make broader operations that don't belong to just one
aggregate then you should think about doing it in the Application Layer,
using an orchestrator, or in the domain using a Service class. And if
dependencies between aggregates are complex that really means that you got
the model wrong.

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.


It is important where your logic lives when you're doing DDD.

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.


DDD can use frameworks, such as ORMs and linq, just take a look at the demo
from Eric Evans and you'll see that he's using Hibernate. No need to hide
it away as soon as it doesn't mess too much with the domain.

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.


UI is not a requirement per se, the business defines the requirements and
UI may be one of the requirements. If it is then the domain must comply.
Otherwise it doesn't matter. There are domains that respond to many
different types of clients, some are UIs others are rest apis, others might
be monitors or jobs.

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.


You need to understand about bounded contexts and subdomains. You should
never have a core domain that includes everything. A core domain should be
very specific to solve a class of problems that are very specific to the
needs of your business, something that sets your business apart from other
business. For many other parts of the system you don't even need to use DDD.

*Joao Oliveira*
*Software Engineer*

*P:* +353 831 467 299 | *E: *[email protected]  | Connect with me
on Linkedin <http://ie.linkedin.com/in/jnicolau>

On Tue, Dec 2, 2014 at 8:48 PM, Rikard Pavelic [email protected]
[domaindrivendesign] <[email protected]> wrote:

>
>
> 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/
>  
>