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.
2
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)
1