Help needed for improvement about modular-monolith-with-ddd

[kgrzybek]

With full respect for Jimmy's Bogard work and his Automapper library - do not use it (and any of mapping libraries) in more complex projects - this is my opinion and advice.

Commands and Domain Events should be immutable. Public setters and parameterless constructors remove encapsulation - this is nightmare of most codebases which I see regularly. Don't do it.

Private setter is much better solution but still not ideal. It breaks immutability *intention". Additionally, as far as I know, there is performance difference in CLR between no setter and private setter (I cannot find any reference now).

I used Automapper long time ago (6-7 years maybe) but I stopped. For me creating mapping in code is not a deal. It is easy and quick and with removed "primitive obssesion" I have a lot of compile-time checks and support. Sometimes more code is not bad. I don't want to use external library in this case.

To sum up - don't use mapping library or use mapping library which supports private setters. I strongly recommend former.

[rmaziarka]

There was a discussion on AutoMapper on Twitter once - the quick summary was that AM is worth using in Domain ->ViewModels (you minimize the data that needs to be downloaded from the database) but not in Request -> Domain (because you start to store your business logic in mappings).

[kgrzybek]

I think we all agree that using mapping library in Command handling is not good idea. Let's move to Queries :)

If you use microORM like Dapper you have everything out of the box - projection to type, selecting only needed columns etc. Mapping library is not needed.

So maybe one of the reason to use it is mapping Domain Entity to DTO? I don't think so. Domain Model is optimized for writes, not reads. You should not use it for reading. In this application you cannot even do it because all fields are private.

So if you don't have true Domain Model and you use EF as data access tool to Data Model why not to return data models (EF entities) directly? EF supports projections I think.

Maybe I am missing something so please add some reference to repository or good article why is better to use Automapper in cases which I described.

[pmikulicz]

command is an intention which shouldn't be modified so it is good idea to keep it immutable. i think most current mappers should deal with private setters so the best way to achive this is to explicity implements private setters

[Morreed]

There's an argument that commands are statements about something that happened and therefore should be immutable, and it allows for the command (or any MediatR IRequest) to be passed around without worrying about it being modified.
I'm a fan of defensive programming and making such object immutable is a good idea IMO, but I've seen many implementations of CQRS that use mutable 'requests', even Jimmy Bogard uses public setters on IRequests in his examples.

[Morreed]

It might be worth adding that Jimmy Bogard uses AutoMapper to map to commands which then act as a Viewmodel , which is different usecase (and a violation of Single Responsibility Principle), but for his simplistic quick architecture demo it's sufficient, anything more than that could be reasonably considered overengineering.
I would not cast AutoMapper away completely, it's a perfectly valid tool to use even in complex projects, but on Read Model side (when mapping/projecting to viewmodels or DTOs). It should not be used on write side.