Strategy to mapping back ViewModels to Domain Entities

[Gustavo Cruz]

Hi everyone,

This question is not about CQRS, but to DDD and Architecture strategy.

My team is experiencing a problem with our ERP, more specific in scenario of mapping between Domain Entities and ViewModels.

Our project have a classic DDD Architecture, with ASP.NET MVC. The Application Services are responsible to build the ViewModels and back it to Presentation Layer. We use AutoMapper to make the map between those objects. 

And here the problem appears:

The map of Domain Object to ViewModel is a quite simple...no doubts here. But the Mapping between ViewModel´s and Domain Object´s has been painful, because we need objects in a valid state. 

Our domain objects have Private Set´s and the behaviour is changed via method´s like ChangeUserAddress(Address address), something already usual by everyone. And we have really complex domain object´s with, for example, a lot of navigation properties.

If we use Automapper to make the map back, the validation doesn´t work, because it´s made via reflection by AutoMapper.

So, what are the strategies I can use to overcome this problem?

[peter....@gmail.com]

“So, what are the strategies I can use to overcome this problem?”

Don’t use Automapper for writeside.

It’s not intended to, and frankly, if you succeed in using it you’re doing crud anyway.

Been there, done that, it was a pain, and came from my own inexperience at the time.

/Peter

--
You received this message because you are subscribed to the Google Groups "DDD/CQRS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dddcqrs+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Dennis Traub]

1. What is a "classic DDD architecture"?

2. Mapping domain classes to and from view models basically wrapping arbitrary method names around a CRUDdy user interface has nothing to do with DDD really, it just makes things complicated.

Strategies to overcome this problem: 

• Make yourself familiar with the concepts behind DDD by reading the book by Eric Evans. And not just chapters 4 through 7.
  
• Figure out if DDD brings value to your project or if it's still just CRUD you're trying to do.
  
• Get rid of generic O/RMs and automapper wherever your model has a complexity that goes beyond just pushing data structures around. A proper domain model will probably barely look like your database tables or client-side views.
  

Happy coding

Dennis

[Gustavo Cruz]

@Peter, you are right.

@Dennis, thanks for the answer.

1. I said a "Classic DDD architecture" only to illustrate a common .NET architecture with DDD (A domain (or domain´s) layer, infrastructure, application and presentation). Maybe i´m wrong.

2. I know that mapping has nothing to do with DDD. It´s more a architecture problem. But I think domain entities can be very simple (and be CRUDdy) and can be very complex too, IMHO. I can have a entity with a lot of fields that are simple and contain no logic. In terms of architecture, it can be a problem in the mapping scenario.

3. I didn´t read the blue book. Only the "red book" by Vaugh Vernon. But it is on my plans :)

Gustavo Figueiredo
.NET System Architect
+55 31 9253.5062

[Kijana Woodard]

Your entire solution doesn't have to follow a single architecture. For the parts that are crud, do crud. Forcing fancy architecture is folly. 😄

Instead of trying to map a view model to a domain entity, send a command to the domain entity........….and, fwiw, I generally map http requests to commands using the model binder.

[Jimmy Bogard]

Yes, please, please, please don't use AutoMapper for writes. I never have, never will. It's not its intention, nor ever will be. It's a hard problem, and my brain hurts trying to solve it, especially that it's a problem I don't ever want to solve. Code for writes is almost always more complex than projections. It's not something I want or intend to abstract away. If you want lossless serialization/deserialization, this library won't do it.

[Trosin Artur]

reagrding mapping "Mapping between ViewModel´s and Domain Object´"... just thinking, it is commonly accepted to use an ORM to "map" Domain Model to DB Tables (and back),
why (conceptualy) View Models to Domain Model which is Object to Object mapping is a big No No...

[Kijana Woodard]

commonly accepted != good idea

[@yreynhout]

It's not because you can kiss your sister, that you should.

[Phil]

I am not sure I think kissing your sister or mapping DO's to ORM's is "commonly accepted".  

Once you are actually doing "real DDD" though the thought of that mapping becomes very awkward.  DO's don't expose their state via a bunch of properties.  DO's expose behavior....so how do you map behavior(e.g. methods) to your ORM?  I haven't used ORM's more than just the EF basic tutorial stuff, but I don't see how it would work.

Phil

[Gustavo Cruz]

Phil, you answer illustrates the exact problem that i´m experiencing. 

Once my DO´s exposes behaviour, how to make a effective communication between presentation layer and Domain Layer? How to translate it?

I´m not want a "magical solution" to make things easier. Just want hear how other people solved this.

[Phil]

One answer would be a read model.  Your presentation layer, at least for display, could be getting the data from the read side (read model), instead of the write side (domain model).  

This could really turn into a long discussion, but I would encourage you to read a bit more into CQRS and event sourcing.  Not that those will be the final answer in your case, but even if they are not I think the ideas they present will lead you down a path to your eventual answer.  

Basically the end answer is that DO's expose behavior, not data, so you need to get your data from somewhere else.  A read model can solve that pretty elegantly.

Phil

[Kijana Woodard]

View Models on the read side.

Commands on the write side.

If your commands boil down to "make all these values in the db match up with this form", you have a CRUD feature. Skip the DDD stuff for that case and shove data into the db.

[sventevit]

If you want your domain objects to always be in a valid state, then the mappers from DTO->DO should be smart enough to do it, right?

For example - if I want to map OrderDTO to Order and the only way to check validity of the Order object is to perform a database query, then this is the responsibility of the mapper? In this example the workflow is like this:
Presentation layer (own assembly) sends OrderDTO to Service layer (own assembly). The Service layer uses Mapping module (also own assembly) to map incoming object to Order type (what happens next is not important - some domain logic & infrastructure calls). But here the mapper should perform a database query to check for validity of the incoming object.

If this is the case, a lot of business logic will be in the mapping module, not in domain layer. Is this OK or do you have any other suggestions?

[Jimmy Bogard]

I don't have an "OrderDto", I have a command, "PlaceOrder". I might be able to do this: Order.PlaceOrder(placeOrderDto) instead. You don't map commands to entities, entities accept/reject them and apply whatever behavior internally from the command data.

For more options, visit https://groups.google.com/d/optout.

[Gustavo Cruz]

Jimmy, I was a bit curious with that approach. What is Order in this context? A Domain Entity? I never seen before a DO receive a DTO in a method (or a ViewModel).

Gustavo Figueiredo
.NET System Architect
+55 31 9253.5062

[sebastian]

this gets to an interesting debate we had on one of my projects. Should entities accept commands as messages or expose a simple interface instead, i.e. callable functions? i.e. should we say person.Retire(retireDto) or person.Retire(DateTime.Now)? We started with the former, and there are clear benefits. (Testing, for instance.) Though we quickly found this defeated many opportunities for programmers to introduce useful value objects. The messages ended up being anemic value objects, and we even found logic being done on them. 

We ended up endorsing an approach whereby the application service is expected to process a command, responsible for message deconstruction, unit of work, and scheduling. We decided the vagaries of serialization (missing fields, default values, whatever) should be a bit of an infrastructure concern, and that the entities should accept only value objects (or obvious naked types) for arguments. 

Certainly either way around, the application service is also responsible for finding the right entity, presumably by loading it from some repository. Automatically mapping from the DTOs to the entities just seemed a little too clever; too much magic.

Anyone else with experience unpacking DTOs in the application service versus in the domain object?

Sebastian Good

[sebastian]

I've had this conversation a bunch of times recently (why would a domain entity take a DTO?) and wrote up my experiences in this area: a few practical observations. Would be keen to see if others had differing experience.

http://www.palladiumconsulting.com/2014/04/command-objects-or-interfaces/

Sebastian Good

[Yin Zhang]

Do you think a command handler function to unpack DTO and route it to the entity is cleaner?

I also believe that if you want to unpack a DTO in entity, say retireDto, it maybe you are missing a business concept? Should it be:

var retireDate = new RetireDate(...);

person.Retire(retireDate)

This allows better encapsulation I believe?

[@yreynhout]

DTOs tend to do what their name implies, nothing more, nothing less. So, yeah, I can follow your reasoning. Many seem to not understand that DDD is (among others) an evolutionary, model centric approach to software development and that aggregates, entities, value objects, repositories, factories, domain events & services (in an OO language at least) are tactical <<patterns>> model concepts get classified into (and so us devs have some definitions to bicker about ;-)). What I'm getting at is that you tend to evolve the model first (you know, a set of abstractions that solves a problem in the domain) and somewhat separate, if only in your head (or as a team effort, duh). DTOs are at best the thing that lands in your application service (you can build those without DTOs as well). Because at the end of the day, that behavior inside the model needs invoking (and there are lots of ways you can do that). But since it takes a lot of effort to crank out a decent UI (with bickering about which client fx and libs to use), remote facade (with bickering about rest/soa/micro/vnext), and some data storage (with bickering about acidity and other aspects of the underlying store) as a whole, the careful crafting of a model - somewhat in isolation, with a lot of polishing, communication, focus on language, collaboration along the way - gets pushed back into a dark, dusty corner (if any effort is spent on that at all). Hence why these "shortcuts" seem to pop up, because too much mapping is a violation of "DRY", no?! So, let's just shove our messaging constructs right into the model and create some nice coupling. No, thank you.
But never say never, since there might be other languages, paradigms, ... that do away with all this bad-taste-in-mouth.