On layered architecture with ddd

Question

I've been working on an architecture, trying to learn more about DDD, layered architecture, etc.

Here's what I have:

Domain
Here I have my entities, the classes that directly map to a database table. I have an Infra where I declared enums used by the entities, my UserManager and ClaimManager, and a few claims, such as StaffClaim. The last thing I put in here is the interfaces for the repositories, such as IStaffRepository.

First question here: is this the right place to put my claims, roles and managers? I feel like this is right for the claims and roles because they are part of what I have come to understand as the domain. However, I feel weird putting the managers used by the repositories here.

Moving oo to the DAL.
DAL Here I have my entities configurations, such as relationships, columns restrictions, database indexes, etc. In this layer I created the concrete implementations of the repositories, the daatabase context, and an interface that opens up the DAL for communication that I call IUnitOfWork.

Moving on...
Services
Here I only have the concrete implementation of the IUnitOfWork exposed by the DAL.
This class exposes the repositories interfaces, and a few other methods, such as OpenDbConnection and StartTransaction.

Next, I created an MVC project as the UI.
UI
Here I have my views, viewmodels, controllers, and API.

Second question
So, from a controller, I can do this kind of thing: unitofwork.Staffs.GetById().
Now, this is where I'm lost.
I need to return half baked entities from the repository, I will use queries like this a lot:

from s in set
where <condition>
select new { Id = s.Id, Name = s.Name }

This creates an anonymous type, which cannot be returned by the repository. I need a class to represent this incomplete entity. Where should I place this kind of classes? I will need many, many such classes. It doesn't feel right to place them in the Domain, and it doesn't feel right to place them in the Service, where my UnitOfWork is, because then I will have my DAL referencing my service.

Answer 1

Starting with your domain. Manager-type classes generally don't represent a domain object, rather, are used to help coordinate domain objects as part of a use-case. As such, this kind of object generally falls under the purview of your application layer (where such coordination belongs). I can't really offer a more pointed explanation without a more specific description of how you are using your Managers.

As for your UI layer, as long as you aren't conducting business logic with your "half-baked entities" (although they are not entities if they are not fully hydrated), you may retrieve data however you see fit. There is no need for a Repository to mediate the flow/mapping of data from your store into your domain, because you needn't use domain objects for the read-side of your application. Returning simple, raw data sets is perfectly acceptable. If you care about type-safety it may be in your best-interest to create DTOs, but often as is the case when numerous ad-hoc reads are required, this is just more work for little benefit.

The most bang for your buck regarding DTOs will be using them as part of your command infrastructure (application layer) to bring type-safety and simple validation for data destined for a command handler.