Re: Is IoC containers harmful for DDD?

On Wed, 3 Dec 2014 15:15:55 +0000
"João Oliveira [email protected] [domaindrivendesign]"
<[email protected]> wrote:

> DDD is not for facilitating HTTP protocols. DDD is used to make it

Nobody implied that? I stated that if you redefine DDD boundary it can
have different meaning.
Let me try and explain it this way.
You have two companies exposing their domain model to other companies
through http layer (last year talk in London was about that).
What I'm saying is that they can expose same exact model to the http
layer and have totally different internals.
If DDD is about internals and how you write your code, then I guess I
am mistaken and all of my rant is wrong.
But if DDD is about building up ubiquitous language, mapping business
talk to domain events/aggregates and their behavior and all other stuff
which is useful, but doesn't require OO then I might be just
misunderstood.

> 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

While this may be the goal of DDD, it's the goal of every business app,
even those which don't practice DDD, so it doesn't mean much.
And assumption that to change domain at fast pace you need to use OO
(combine data and behavior) is only that, an assumption.

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

Of course that you want to invest most in the core domain. I'm just
saying that some of the explanations of DDD are not really good. Even
Evans tried to "redefine" what DDD means to him today.
DDD != OO. And most useful parts of DDD can still be practiced while
doing some less useful parts differently.

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

I didn't say aggregate is a service, I said people often try to jam
service behavior into an aggregate.

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

Requiring multiple updates at once doesn't mean dependencies between
aggregates are complex.

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

What I'm saying is that I can have logic implemented in my stored
procedures and still do DDD.
What I'm trying to point out is that the layer behind which you state
that the model lives can be more loosened up than a class in OO
language.

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

Of course it can. Just common advice is to avoid it.
And I've seen examples from Evans many years ago, don't see why you are
trying to point that out, unless you think I don't know what DDD is and
have read about it recently, so I'm confused what it means.

Especially since I've done much more technical work in MDA/DDD space
then most guys (which you could found out if you visited links in my
signature).

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

Please note that I do understand what DDD means and I'm perfectly aware
that in large ERP system you'll have multiple core domains.

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/