C# – Should I use different projects for building different layers in a 3-layer model

The four layers you mentioned match the names of the layering I've used when I recently architected two our our company solutions. I also strongly agree to @Konamiman reply, Data Access and Infrastructure shall be two separate layer. In our solutions Infrastucture is a cross-cutting layer which can be referenced by projects in any layer. In the infrastructure layer we keep the logging functionality, security and validation code.

I would also consider adding a layer below the Data Access Layer called Entities. Put all your business object there, add Interfaces of of the entities in the Data Access Layer and reference the Data Access Layer with the Entities project.

I'm used to using non-strict referencing as you described, an upper layer can reference any of the lower layers. In a strict referencing an upper layer should only reference the the closest lower layer.

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)