4

I'm reading a crapload on all these subjects:

POCO
Repository Pattern
Unit of work
Using an ORM mapper

ok I see the basic definitions of each in books, etc. but I can't visualize this all together. Meaning an example structure (DL, BL, PL).

So what, you have your DL objects that contain your CRUD methods, then your BL objects which are "mapped" using an ORM back to your DL objects? What about DTOs...they're your DL objects right? I'm confused.

Can anyone really explain all this together or send me example code? I'm just trying to put this together. I am determining whether to go LINQ to SQL or EF 4 (not sure about NHibrernate yet).

Just not getting the concepts as in physical layers and code layers here and what each type of object contains (just properties for DTOs, and CRUDs for your core DL classes that match the table fields???).

I just need some guidance here. I'm reading Fowler's books and starting to read Evans but just not all there yet.

Daniel Hilgarth
  • 171,043
  • 40
  • 335
  • 443
PositiveGuy
  • 46,620
  • 110
  • 305
  • 471
  • 1
    Lots of questions here; which makes it difficult for me to answer. Read some more (for instance the links Vsevolod posted in his answer), try out some concepts and then post a specific question. Then we can help you better. Literature-wise I'd say you're on the right track; but indeed: it's a lot to grasp at once. – Marijn Dec 31 '10 at 09:06

1 Answers1

7

I will assume that DL - Domain Layer, BL - Business Layes and PL - Persistence Layer.

If you need a simple CRUD application you should not use DDD principles. Use DDD if you have a complex domain model to implement.

In DDD you will have DL and BL combined with ALL the logic inside your domain objects/services. Otherwise you will build an Anemic Domain Model. Avoid setters on properties and change your objects only via method calls like ChangeAddress instead of obj.Address = newAddress or Activate instead of obj.Active = true.

Data-Transfer-Objects should be used only for communication with external services/UI. Inside your domain you will use Domain Objects only.

I suggest to use task-based UI.

What persistence technology to use in Persistence Layer depends on your requirements. Before you will choose SQL RDBMS take a look at Object-relational impedance mismatch wikipedia page.

For the implementation samples please check related questions:

  1. Are there any open source projects using DDD (Domain Driven Design)?
  2. Good Domain Driven Design samples
  3. .NET DDD Example
Community
  • 1
  • 1
Seva Parfenov
  • 991
  • 1
  • 8
  • 6
  • awesome, this is just the advice I'm looking for. Now, I know someone who for a .com is using LINQ to SQL to stub out their Data Layer (DL) classes (crud methods) but then using a repository / unit of work pattern for handling the domain logic and persistence. I mean they're sort of using both I think...that's what I'm trying to decide here. But using DDD is just good isn't it? because you're not tying your BL (Business Layer) logic tightly to the persistence layer so I would think it's good for any system but then you are saying there may be a performance hit for using DDD?? – PositiveGuy Jan 01 '11 at 04:42
  • I've worked for a few .coms and we did not use DDD, just tightly coupled DL to DB either by coding custom entities or something like CodeSmith templates to stub out entities. But now I've seen places that I've been interviewing with that swear on DDD and are all e-commerce .coms. I'm working on my own .com on the side so that is why this is all overwelming to me. I'm trying to get more advanced here for the sake of making my app much more flexible, clean, and extensible rather than going the strictly strong couple from DL to DB...but then DDD brings in abstraction of your BL to DL right? – PositiveGuy Jan 01 '11 at 04:44
  • If I keep a clean separation from BL to DL, I could essentially swap out my DL if I ever needed to in the future as well...so isn't that what DDD is all about?? That you're BL logic is not tightly linked to your DL. – PositiveGuy Jan 01 '11 at 04:45
  • @CoffeeAddict DDD is about tackling complexity of software. To do that - You must know what it's supposed to do, model that explicitly and encapsulate that from boring parts like interaction with asp.net and entity framework. – Arnis Lapsa Jan 01 '11 at 22:01
  • @Arnis. Well "complexity" is a relative term. I mean that could mean anything in any certain person's view. What I mean is, DDD promotes good abstraction (BL is ignorant of how DL gets the stuff or makes CRUD operations when making BL method calls) as well as ensures that you do not tie your domain objects tightly to the Relational Database Design or your Data Layer which the Data Layer core entities will naturally have to be closely mimicking exact DB table structures (in terms of # of fields/properties, names of those fields) – PositiveGuy Jan 02 '11 at 05:04
  • @CoffeeAddict those things are by-products that makes domain driven design possible. Real benefit is successful management of complex business logic. – Arnis Lapsa Jan 02 '11 at 11:49
  • 1
    @CoffeeAddict domain logic-repository/unit of work-LINQ to SQL - as you see repository here is an abstraction which allow you to hide your persistence code from domain. This is why you better use a Repository pattern. Treat this pattern as an abstraction layer, not as a persistence technology. DDD is not about separating persistence from domain. DDD is about how to write your domain code. Ubiquitous language, bounded contexts - that's what main in DDD. And to do this you MUST separate persistence from domain. – Seva Parfenov Jan 03 '11 at 07:18
  • 1
    @CoffeeAddict You start to talk about performance - this is very separate topic and if you really need fast code you need to minimize how many method calls you do to perform something. It will strict your ability to layering your code. But think twice if you really have such a requirements. – Seva Parfenov Jan 03 '11 at 07:19
  • 1
    @CoffeeAddict Yes, DDD brings in abstraction of your BL to DL. But as a sort of side-effect. Again, DDD is about how you organize your domain-related code to make it cleaner and look more how business understand it. Hence DDD is best when domain is complex. – Seva Parfenov Jan 03 '11 at 07:24
  • thanks Vsevolod, did not know that about DDD and persistence. – PositiveGuy Jan 04 '11 at 05:26
  • @Vselolod Gotcha on the "if you really have such requirements". But I've seen a lot of .coms that are your standard e-commerce site that swear on DDD...that really don't have anything mind boggling in the Domain. So ...it seems like DDD is the way to go even for your routine e-commerce site. Take for example Redbox, Stackoverflow, Entertainment.com, etc. All use DDD. – PositiveGuy Jan 04 '11 at 05:28