Re: Is IoC containers harmful for DDD?

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

When exposing a services via http you expose an interface which may
resemble the model but not necessarily. Those companies can expose the same
interfaces and still using totally different approaches, one using DDD and
another something totally different. DDD cares about how you translate the
business into a model not how you expose the model, unless exposing the
model in a special way is part of the business requirements. So yes DDD do
cares about internals and that's why we need the patters such as aggregate,
specifications, factories,...

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.


Not every business app needs to be answer to a fast changing business
requirements. And not all parts of the the business need to care using DDD.
Think about apps that are working for banks and Nasa missions for many
years doing perfectly fine without any changes. Think about CRUD
applications that trade a rapid development for a less consistent domain
model. To do DDD one must combine data and behavior, otherwise it would be
something else... if you leave logic out of your entities you get a Data
Driven Development.

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.


If you are doing DDD with stored procedures owning business logic you are
doing it wrong.


*Joao Oliveira*
*Software Engineer*

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

On Wed, Dec 3, 2014 at 4:14 PM, Rikard Pavelic [email protected]
[domaindrivendesign] <[email protected]> wrote:

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