Understanding DTO and Anemic Domain Model

Question

I am new to Domain Pattern, I need to ensure that I understand what I had read so far!!, Please tell me whether the following sentences are true or did not violate a principle related to DDD

enter image description here

0) DAL will receive parameters in DTO and return fetched data in LIST of DTO (Entity)

1) De-couple BLL and DAL through repository pattern.

2) Entity is DTO object.

3) ProductCategoryData contains a list of ProductData.

4) It will be Anemic Domain Model ANTI Pattern if BLL.ProductCategory does not contain properties that describe the business object.

5) BLL.ProductCategory contains a List of BLL.Product……I have bad feeling about this

6) I avoid in that design anemic domain model anti pattern.

7) I successfully Apply Domain Model Pattern.

8) I used DTO objects to transfer data between tiers.

Please talk to me :)

duffymo duffymo · Accepted Answer · 2011-06-21T16:12:57

Why do you have a bad feeling? Anemic sounds like a bad word, but what harm have you detected?

I see objects that don't have any behavior as anemic. I don't judge by data members.

If you choose for other reasons to move that behavior somewhere else (e.g. services), there's an argument that you're choosing an architecture that's more functional than object-oriented. Is that really so bad?

I think labels like anemic can sound bad, but they really just describe one person's design decision. It might also reveal someone's OOP bias. A functional language would be considered anemic by an OOP practitioner, but it's not necessarily fatal.

A better question to ask is: "Do I have parallel models? One for DTO and another for business layer?" If yes, I'd say that dual maintenance is far more harmful than anemia.

Understanding DTO and Anemic Domain Model

2 Answers