DDD vs N-Tier (3-Tier) Architecture

I have been practicing DDD for a while now with the 4 distinct layers: Domain, Presentation, Application, and Infrastructure. Recently, I introduced a friend of mine to the DDD concept and he thought it introduced an unnecessary layer of complexity (specifically targeting interfaces and IoC). Usually, its at this point, I explain the benefits of DDD-- especially, its modularity. All the heavy lifting and under the hood stuff is in the Infrastructure and if I wanted to completely change the underlying data-access method, I could do so with only having to touch the Infrastructure layer repository.

My friend's argument is that he could build a three tiered application in the same way:

Business
Data
Presentation

He would create business models (like domain models) and have the repositories in the Data layer return those Business models. Then he would call the business layer which called the data layer. I told him the problem with that approach is that it is not testable. Sure, you can write integration tests, but you can't write true unit tests. Can you see any other problems with his proposed 3-tiered approach (I know there is, because why would DDD exist otherwise?).

EDIT: He is not using IoC. Each layer in his example is dependent on one another.

I think you are mixing a few methodologies up. DDD is Domain-Driven Developement and is about making the business domain a part of your code. What you are describing sounds more like the Onion Architecture (link) versus a 'normal' 3-layered approach. There is nothing wrong with using a 3-layered architecture with DDD. DDD depends on TDD (TestDriven Developement). Interfaces help with TDD as it is easier to test each class in isolation. If you use Dependency Injection (and IoC) it is further mitigated.

The Onion Architecture is about making the Domain (a.k.a. business rules) independent of everything else - ie. it's the core of the application with everything depending on the business objects and rules while things related to infrastructure, UI and so on are in the outer layers. The idea is that the closer to the 'shell of the onion' a module is - the easier it is to exchange for a new implementation.

Hope this clears it a bit up - now with a minor edit!

Hmmm... I am very familiar with Jeff Palermo's Onion Architecture, as my project has those distinct layers within it and I based it around his blog post. Yet, all of these layers also exist in a DDD project as well (e.g. Domain, Application, Presentation, and Infrastructure).

Josh Barker 2010-09-30 19:28:46

My point was that although the union structure is used by many who also use DDD - it is not a prerequisite for DDD.

Goblin 2010-09-30 19:35:21

To further elaborate - to practise DDD - you do not need a specific set of layers nor do they need to be structured in a specific way. However, everything you code should model the domain you are targeting including business objects having the same names as their real-life counterparts.

Goblin 2010-09-30 19:38:04

Yet the difference is that within the 3-layered approach I described, without using IoC, is that every layer knows and depends on each other... isn't that an anti-pattern?

Josh Barker 2010-09-30 19:41:41

It isn't an anti-pattern per se, but I agree that using the onion structure makes the coupling looser as the business layer isn't dependant on the infrastructure layer. I much prefer the onion over the traditional 3-layer model. But I still believe it is fully feasible to use a 3-layered architecture if you don't believe in exchanging e.g. your ORM: see this link for why: http://ayende.com/Blog/archive/2010/07/30/the-false-myth-of-encapsulating-data-access-in-the-dal.aspx

Goblin 2010-09-30 19:56:41

Using an IoC container is a trade-off as it introduces complexity for looser coupling. It's all about what you need. EDIT: And you can still use interfaces and dependency-injection between your layers in a 3-layer architecture to facilitate testing.

Goblin 2010-09-30 19:58:30

I am starting to understand where you're coming from... if you edit your answer, I can switch my vote.

Josh Barker 2010-09-30 20:14:15

Did the editing.

Goblin 2010-09-30 20:16:45

How can something be easily unit tested without using IoC? He can have integration tests, but how would you do unit testing without interfaces/IoC/DI?

Josh Barker 2010-09-30 20:11:58

what I'm saying is that DDD or N-Tier doesn't imply IoC or not. It seems like you are trying to focus the question on DDD vs. N-Tier, but what your question really seems to be asking is IoC/DI vs. no IoC/DI. fwiw, I'd be on your side supporting IoC/DI. I just don't think DDD or N-Tier are relevant at all, since either can be done with or without DI/IoC.

qstarin 2010-09-30 20:27:56

ansaurus

tags:

views:

answers:

DDD vs N-Tier (3-Tier) Architecture

related questions