Re: Is IoC containers harmful for DDD?

Agree with most of the comments however...


> I don't think this breaks with DDD ideas at all. Implement your
> functionality in a way that supports your business case - if that requires
> you to use a stored procedure then do so. I think it's a common
> misconception that your model has to be restricted to objects. In fact it's
> a misconception that you have to use OOP for DDD at all.


Implementing DDD with stored procedures is wishful thinking. You wouldn't
get any benefit from doing so. As with any other task, using the right
tools makes it easier. I would even argue that a new language could be
created just to support 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 Wed, Dec 3, 2014 at 12:36 PM, Thomas Presthus [email protected]
[domaindrivendesign] <[email protected]> wrote:

>
>
> On Tue, 2 Dec 2014 21:48:08 +0100, "Rikard Pavelic [email protected]
> [domaindrivendesign]" <[email protected]> wrote:
>
> > I think it boils down to what it means domain boundary to people.
>
> Definately. In addition, I think that there's a lot of confusion to what
> DDD actually is. For me it's about tackling complexity in software by
> aligning it to the business, instead of creating software in a merely
> technical perspective. The most valuable parts of DDD is, in my opinion,
> the strategic design ideas: Communicating with domain experts, establishing
> and evolving a ubiqitous language and crafting models that solves our
> business problems. A key ingredient to crafting such models is to support
> the actual business scenarios, which I'll go into detail about below.
>
> > 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).
>
> I've found that this is often a result of poorly designed aggregates. When
> developers read the blue book, they usually start identifiying aggregates
> from database tables / their existing model. I struggled with this myself
> for a long time. The notion of having a Customer aggregate, an Order
> aggregate, etc. made it really hard to change only one aggregate in
> isolation.
>
> However, if you design your aggregates with the actual use case in mind
> you'll find that aggregates can be very different to our standard
> normalized database model. I remember Udi Dahan's talk about Domain Models
> and Composite Applications
> (https://skillsmatter.com/skillscasts/1806-talk-from-udi-dahan)
> enlightened
> my view on this.
>
> > 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.
>
> I don't think this breaks with DDD ideas at all. Implement your
> functionality in a way that supports your business case - if that requires
> you to use a stored procedure then do so. I think it's a common
> misconception that your model has to be restricted to objects. In fact it's
> a misconception that you have to use OOP for DDD at all.
>
> > 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.
>
> I fail to see how this has anything to do with DDD. I can't recall reading
> anywhere that DDD tells you to implement your own frameworks. I do however
> think that crafting software in the simplest way possible gives you more
> time to focus on your core domain and modelling. I also beleive that
> introducing less magic in your software makes it easier to evolve, support
> and understand. This goes along with your statement that most frameworks
> are bad ;)
>
> > 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.
>
> I'm not quite sure where you're headed here. I've often found that the
> interface to the domain is the interesting part. The UI can very well be
> this interface, and thus it should be considered part of your model.
>
> This does however get a little blurred when you start thinking about CQRS
> and composite UIs that span several contexts. In such cases, I like to
> treat my different UI components as living in different bounded contexts,
> thus removing the separation of "UI and domain".
>
> > 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.
>
> Again, I've never seen someone preaching DDD say that joins are bad. The
> database could be treated as a model of it's own, and implemented in a
> data-friendly way. Again, DDD is about solving business requirements ;)
>
> --
>
> Thomas Presthus
>  
>