We Keep Coding

DTO vs. Domain Model, project organization

I have a project with a repository, a service layer, using EF6 and code-first POCOs. In the CustomerRepository, I am doing several projection queries that return objects.
I understand that the code-first POCO's are what would be considered "Domain Models", but if I were to do a projection query into a different model, what is that model considered? An example of this would be the CustomerOrderStats. Is that still a Domain Model, or should that be considered a DTO model?
Example
Object returned from Repository:
public class CustomerOrderStats
{
public string Name { get; set; }
public int Count { get; set; }
}
Query in the Repository
public CustomerOrderStats GetCustomerOrderStats(Guid customerGuid)
{
return customers
.Where(c => c.Guid == customerGuid)
.Select(new CustomerOrderStats
{
Name = c.Name,
Count = c.Orders.Count()
};
}

It could be either one, really. The definition of a model vs. a DTO isn't really a matter of how you organize any given framework, but rather what that object represents in the domain. If it has rich functionality or business logic or is an active part of the actual business process, it's probably a model. If, on the other hand, it's just a container of properties to move values from one place to another, it's probably a DTO.
The key here is whether the object is an active part of the business process. And a good rule of thumb here is often the name of the object.
Is it a name that non-technical business team members understand?
Is it a term they use to describe what the business does? (Even a very small part of the business)
Does it carry a meaning in the industry in general?
A DTO is generally something that exists for purely technical reasons. Component A needs to send data to Component B, but that operation is a technical one and not a business one. Data just needs to be, well, transferred. As a piece of the system, it's essentially built "from the bottom up" because it satisfies a low-level technical need.
A model describes a part of the business. It could be an element on a chart which defines the business process in non-technical terms, or an encapsulation of a business concept. As a piece of the system, it's essentially built "from the top down" because it is described generally by the business and then implemented specifically to meet that need.

Business logic layer needs its own models or not

I'm doing 3 tier application using asp.net mvc and I want to do everything as recommended.
So I've done MvcSample.Bll for business logic, MvcSample.Data for data and MvcSample.Web for website.
In Data I've my edmx file (I'm using database first approach) and my repositories. And in Bll I'm doing services which will called in web.
So my question is that:
Should I write other models in Bll or use that ones which are generated in edmx file?

It heavily depends on the type of problem that your application is trying to solve.
From my experience, it is very rare that the business logic returns model objects directly from Entity Framework. Also, accepting these as arguments may not be the best idea.
Entity Framework model represents your relational database. Because of that, its definition contains many things that your business logic should not expose, for example navigation properties, computed properties etc. When accepting your model object as an argument, you may notice that many properties are not used by the particular business logic method. In many cases it confuses the developer and is the source of bugs.
All in all, if your application is a quick prototype, proof of concept or a simple CRUD software than it might be sufficient to use EF model classes. However, from practical point of view consider bespoke business logic model/dto classes.

From my point of view you need another model for your Bll.
That would encapsulate your Bllcompletely.

I think there is no right or wrong answer for your question.
In my experience, I used both.
Let's see at below example:
I have an User table
public class User
{
public int Id{get;set;}
public string First_Name{get;set;}
public string Last_Name{get;set;}
public int Age{get;set;}
public string Password{get;set;} //let's use this for demonstration
}
I have a Method call DisplayAll() in Bll. This method should list down all users in my database by Full Names (FirstName + LastName) and their Ages.
I should not return User class because it will expose the Password, but rather, I create a new Class UserDto
public class UserDto
{
public string FullName{get;set;}
public int Age{get;set;}
}
So here is my DisplayAll():
public List<UserDto> DisplayAll()
{
List<UserDto> result = ctx.User //my DbContext
.Select(x => new UserDto()
{
FullName = x.First_Name + " " +Last_Name,
Age = x.Age
}
return result;
}
So as you can see, my method DisplayAll() uses both User and UserDto

My approach will be
MvcSample.Data
-- Model Classes
-- EDMX attach to model
MvcSample.Bll
-- Model Inheriting MvcSample.Data.Model
-- Business Logic Class - Using MvcSample.Bll.Model
MvcSample.Web
-- Controller using MvcSample.Bll.Model

It depends on your view about software design and how you want to take advantage of it. by separating BLL model, you will have your freedom to put story specific validation and calculation. By using only DLL model, it is sometimes tough as it is going to take effect in DB.

You can use 3 tier architecture in asp.net in this way
MvcSample.BLL - business logic layer
MvcSample.DAL - Data access layer
MvcSample.Domain - Domain layer
MvcSample.web - website
All your repository classes are including in .BLL layer.That means your logics are stored here.
Usually .DAL is used for storing .edmx classes. .Domain is using for recreate database objects that are useful for server side.That means if you are passing a json object from client to server,Then that object should be create on the server side.So those classes can be implement in the .domain

How to correctly parse complex viewmodel to separate domain models in ASP.NET MVC?

I wonder how could I solve the following case : there are a form on website where manager input very big amount of data to Viewmodel and pass to server-side.
class CitizenRegistrationViewModel {
public string NationalPassportId { get;set; }
public string Name { get;set; }
public List<string> PreviousRegisteredOfficeCodes {get;set;}
// about 30 fields like strings, Booleans, HttpBasedFiles (pdf,jpg).
}
And the problem that in domain this data need to be logically separated and stored in different tables (classes in EF) like CitizensNationalPassportsTable, CitizensWorkingPlaceRecordsTable, etc. There are no complex class Citizen with properties like :
public class Citizen {
public ICollection<CitizensWorkingPlaceRecords> workingPlaces
// etc...
}
but this properties are separately stored in different tables with no one-to-one or one-to-many relations (no FK here) . The only NationalPassportId property could be used as navigation key (unique per user and all records related to user in different tables contains this key).
Should I write big amount of code to parse Viewmodel to domains models like :
public void CitizenRegistrationViewModelToDomainModel(CitizenRegistrationViewModel model){
CitizenNationalPassport passport = new CitizenNationalPassport(model.NationalPassportId);
CitizensWorkingPlaceRecord workplace = new CitizensWorkingPlaceRecord(model.PreviousRegisteredOfficeCodes, model.NationalPassportId);
// 12 extra objects need to create...
db.CitizenNationalPassports.Add(passport);
}
Or is there any more correct approach to handle this problem? I wanted to use AutoMapper, but is it the best solution?
I can't change business models' logic, as it is a legacy project.

You should have a set of classes that represents the data that the browser is exchanging with ASP.NET MVC. Let's name them for example, Input Models. In this classes you have metadata attributes, custom properties and many things that are relates with the exchange between browser and web server.
You should have another set of classes that represent your database structure, those are your Entity Framework POCO classes. Let's name them DB Models. It does not matter how POCO and fancy they are, they always map to tables and columns, so they are always tight to the DB structure.
You should have another set of classes that are your domain classes, the classes you use when operating objects in your business layer.These are binding/persistence/representation agnostic.
You should have a repository that knows how to persist a domain entity. In your case it will be a class that knows how to operate the DB models and the DbContext.
Then, when you get input from your browser, you bind that data to the input models and those are passed to the controller (this is done automatically by the DefaultModelBinder or you can use your own IModelBinder).
When you get an input model, you have to create a new domain entity using that data (in case that is an actual new entity). Once you have your domain object ready, you pass it to the repository to be saved.
The repository is responsible of knowing how to save the domain entity in the database, using the DB models.
In essence, the Controller or the business service instance you operate in the Controller's action context should be responsible of articulate the interaction between these elements without them knowing each others.

AutoMapper or an alternative could be used to automate the mapping from View model to Domain models, but this only makes sense if properties are named identical in View and Domain models. If this is not the case you'll end up writing mapping rules which doesn't help you. It just moves code from your current mapping classes to the AutoMapper configuration. So, if you're in a position to modify your viewmodels I'd go for AutoMapper or anything similar, if not I'd use what you currently have.

In what layer in DDD are classes declared as Aggregates roots?

We have a large application that we are starting to develop using DDD.
We understand the concept of Aggregates (roots) and bounded contexts and repositories, where repositories accept only aggregate roots to be persisted.
What I am not clear about is this. We have auto generated entity classes for each bounded context in the persistence layer, and have a few domain models sitting in the domain layer. We do this to simplify a very complex database structure (700+ tables), which is why, for instance, we have a Customer entity class and related entities that map to a CustomerModel complex type as a domain model.
The IRepository<IAggregateRoot> has Get, Save, Delete, Update CRUD methods.
Given the example above with Customer and CustomerModel, the dbo.Customer table has about 15 other tables that belong to the same aggreagte. But what classes are actually supposed to implement the IAggreagteRoot?
The aggreagte is a logical grouping, but is it done in the domain:
public class CustomerModel : IAggreagteRoot {}
or is it done in the entity class:
public class Customer : IAggreagteRoot {}
To me it makes more sense to define the domain model classes as aggreagtes, because those are visible to the application(s) "sitting" on top of the domain. The entities are for persistance.
Thank you.

I think that you have mixed two concepts here. Everything in domain layer is Your model (domain model): aggregates, entities, value objects etc.
What you named CustomerModel is probably just a DB model (if I understood correctly), and DB models are part of infrastructure level. Domain layer has no knowledge about that.
To answer Your question: Customer should implement AggregateRoot interface.
Example:
infrastructure.ui.show_the_oldest_user:
oldest_user_dto = user_service.get_the_oldest_user()
oldest_user_dto is just a raw data
application.service.get_the_oldest_user:
user = user_repository.get_oldest()
return user
user is an aggregate root
infrastructure.persistence.repository.user.get_oldest:
orm_user = user_orm_model.order('age').desc().one()
user = this.reconstitute(orm_user)
return user
orm_user is an instance of user model from DB, which we have to map to our aggregate root (reconstitute).
This way we have no orm instance flying across all layers which is a really bad coupling. I also map aggregate to dto when I return it from application service, so UI is not coupled to domain model, but it's not a must.

AggregateRoots are Entities, the difference being that they can be accessed from services, views, etc.
Customer, in your example, is an aggregate root.
CustomerAddress is not - so you would make sure that calls to update a customer address went through Customer
customer.UpdateAddress(addressValueObject);
rather than having any way you can deal with a customer's address outside the context of that customer. In other words, you shouldn't have anything like
address.Update(newValue)
outside of the Customer entity.

DDD "View Objects"?

Given an application that involves, say, Companies, I might have a Company class. I will have a data access layer that populates a List <Company>. However, there will be times (such as displaying a search result) where I only need to display the Company name, telephone and postcode properties, and it seems to me that populating the entire Company object with all its properties seems wasteful.
What would be the right way to go about this in terms of a DDD design? Would I create View specific classes, such as a CompanySearchResult object which only exposes the properties I'm interested in displaying?

That sounds like a reasonable approach to me.
Later on, if the customer comes to you asking for your SearchResult to display something unrelated to the Company model - something crazy like the number of nearby ice cream shops you'll have a much easier time appending this to your CompanySearchResult than your domain object.

This is what is typically known as a "view model" or a Data Transfer Object. You may not want your view to have access to the entire data tree exposed by your domain model. Especially if exposing your domain model means that your view will have to dig deep into your object graph to pull the data it needs, a View Model can make alot of sense to simplify working with the model objects. In your case, if you are simply pulling direct properties off of the model object, it would make sense if you want to hide the extraneous data not needed by the rest of your domain model.

The approach you suggest can quickly increase the number of DAO:s you need to create and become a maintenance nightmare. The approach that several ORMs take is to proxy the data access, so your data access layer will return a list of interfaces, and the database call will be postponed until you invoke the data accessor, for instance
list.getCompany(1).getName()
. This is call lazy loading. You will still need to make a trade off between making many small or fewer big queries. This type of tasks is one of the strengths of ORMs, you can usually ask your ORM to prefetch parts of the object graph which you think will be used, and leave out other parts.

I use a crumble of the entity attributes. For example:
// interface for "ID" attribute of Company entity
public interface ICompany_ID {
Guid CompanyID{get;set;}
}
// interface for "Name" attribute of Company entity
public interace ICompany_Name {
string Name{get;set;}
}
// interface for "Logo" attribute of Company entity
public interface ICompany_Logo {
byte[] Logo{get;set;}
}
// interface for all attributes of Company entity
public interface ICompany : ICompany_ID, ICompany_Name, ICompany_Logo { }
// base class for classes based on Company entity
public abstract class CompanyBase : ICompany_ID {
// implementation of ICompany_ID interface
}
// class for all attributes of Company entity
public class Company : ICompany {
// implementation of ICompany interface (all attributes)
}
// class for Company name lookup
public class CompanyNameLookup : CompanyBase, ICompany_Name {
// implementation of ICompany_Name interfade
}
This crumble allow me to work with different attributes of different entities and all is type-safe.
however, your data-layer must support this scenario.
The next way is dynamic creation of lookup classes, but it is much more complex. On the other side, it is much more flexible.
EDIT:
Then the selection can be for example:
var companies = (from c in db.Table<ICompany>()
order by c.Name
select new CompanyNameLookup { ID = c.ID, Name = c.Name }
).ToList();
or for danymicly created types:
var companies = (from c in db.Table<ICompany>()
order by c.Name
select DynamicTypeFactory.New<ICompany_ID>( c.Id ).And<ICompany_Name>( c.Name ).Create()
).ToList();
The DynamicTypeFactory is class with static method New and fluent interface for danymic creation classes at run-time.