Onion Architecture: Should we allow data annotations in our domain entities?

Question

I am looking to implement the Onion Architecture into our ASP.NET MVC application. I understand the need to separate View Models from Domain Entities, however I am finding myself writing redundant code. There is redundant code because my view models and domain entities look exactly the same with the exception that my view models have the [Serializable] data annotation. I need these models serializable because I am using ASP.NET Session State in which the State Server needs objects to be serializable.

I personally feel the domain entities should NOT be serializable because it would then become dependent on a particular technology. However, how can I avoid redundant code?

I should add that my service methods are dependent on these serializable data models.

Septima

You can always look into adding a service via a factory pattern that can serialize and deserialize your domain objects. – Donny

I use an onion architecture (ports and adapters) with DDD on my personal projects and my view models rarely look anything like my domain model. Alternatively when I do database-centric projects for clients, I see them using the same EF model through all the layers and as a consequence I have to listen to the dozens of problems this causes. – Resentment

@MickyDuncan One model is bad for any non-trivial non-CRUD app. It forces you to fit different use cases (concerns) into one place and you end up with a frankenstein's monster . And in time, those models evolve in different ways so you want one model per layer/bounded context in order to keep you sane and productive. A lot of problems in development are because of bad design and going for the quickest/shallow solution. – Palanquin

Answer 1

I would avoid annotating my domain objects with anything persistence or non-domain related. This way, my Domain project wouldn't depend on another layer and I won't have it cluttered with things that aren't relevant to the Domain. While we need to bend the rules, I prefer bending them in a way not involving dependency on a persistence detail.

The point is to keep the layers focused on their purpose because it's very easy to mix'em up and create (in time) the big ball of mud.

In your case, I have the feeling you don't really have a rich domain or it's improperly modeled. It seems you only have data structures and your needs are CRUDy.

If you are certain the app won't evolve to become more complex i.e it will be just data structure manipulations then you can have one model to use them for all the purposes. Basically you can cut corners and use the 'business' model for everything. No need for abstractions and other stuff.

But if you think the app will evolve or they are or will be business rules and processes i.e you'll need to model behaviour as perceived by the business, then it's best to keep things very decoupled, even if at this stage they seem to be identical.

To make it easier, for your view model you can define one (with copy paste) and use automapper to map the business object to the view model one. Other approach maybe that your query service/repository/object could return directly that view model (map the query result to the view model)

Palanquin

+1. This is in essence what I'm trying to explain to another guy facing a slightly different issue there – Favourable

Answer 2

Viewmodels can contain domain entities/models. My domain entities are partial classes and all (eventually) inherit from a base entity which is serialized. Since I use my domain models within some of my viewmodels, I use data annotations on the domain models as well. Your domain model library should not depend on/reference anything else (domain driven).

Mooneyham

Answer 3

I wouldn't call [Serializable] a data annotation per se, since it's part of the core .Net platform (mscorlib.dll). Data Annotations refers to specific attributes used to perform data validation and other operations in ASP.Net or Entity Framework.

Should an Entity be [Serializable] ? Probably not, but I don't think this attribute is as "adulterating" to your domain layer as other attributes that come from external, web- or persistence-oriented libraries. It doesn't tie you to a particular third-party framework.

The whole "redundant code" issue depends IMO on the type of system you're building. In a genuine DDD application, duplication between Domain entities and View Models will probably not be all that blatant, and the benefits of a separate presentation model will typically outweigh the costs. A good article on that subject : Is Layering Worth The Mapping ?

Cony