I have been reading a lot about domain layer and DDD. However I am still confused about it. To me they seem to be a fancy name for business classes however more modelled towards your application domain but then most programmers I have worked with create business object/entities and try to model it as closely as possible to the actual application objects.

So here's the question. In the Asp.net Web API application whose primary focus would be to get large amounts data(GET requests mostly) from different tables on the basis of certain inputs and some logic running as a result, is there really a business need for Domain layer and objects?

**Another thing that I find troubling when I read about DDD is that both DAL and BLL link to Domain Layer which can introduce dependency issues when updating certain parts of the application in the future.

  • 1
    Could you elaborate on your final paragraph? Feb 4, 2015 at 17:48
  • @BenAaronson I just added it as an after thought in an edit :) Basically taking the example of a web application in asp.net having separate projects for Business Logic, Domain Layer & DAL. If both DAL & BLL projects have a dependency on Domain Layer project (as in the case of DDD), then any change to domain project will require at the minimum a recompilation of the other two projects too. This is for bare minimum change otherwise any method/object change in Domain layer would probably require corresponding changes in both BLL & DAL projects.
    – Emma
    Feb 4, 2015 at 18:42

1 Answer 1


I think the business object/entities you are describing aren't actually domain objects in the DDD-sense, if you are applying DDD your business logic would be contained in the Domain Objects themselves; the entities you are describing (having business logic in a separate layer) seem to be Anemic.

If you want to know whether to use DDD you would have to establish whether or not the domain you are working in is sufficiently complex to involve Domain experts as "[f]undamentally, DDD is the principle that we should be focusing on the deep issues of the domain our users are engaged in, that the best part of our minds should be devoted to understanding that domain, and collaborating with experts in that domain to wrestle it into a conceptual form that we can use to build powerful, flexible software." Eric Evans

The fact that you are essentially displaying data from different tables on the basis of certain inputs and some logic would lead me to believe that your domain is not complex enough to warrant applying DDD.

In order to address your last concern, a common DDD architecture would not have the DAL and BLL link to the Domain Layer, the DAL would be abstracted behind a repository which would expose and persist your Domain objects; business logic would be contained in the Domain objects themselves, and your "BLL" would actually be a service or application layer that uses the repository for access to the domain objects, it is "a thin layer which coordinates the application activity. It does not contain business logic. It does not hold the state of the business objects, but it can hold the state of an application task progress". (from the book domain driven design quickly page 30)

  • 2
    Thank you very much! I read more about it and I really cant justify the use of domain driven design for a project which is primarily geared towards data retrieval.
    – Emma
    Feb 5, 2015 at 11:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.