Re: Is IoC containers harmful for DDD?

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


------------------------------------
Posted by: Thomas Presthus <[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/