AutoMapper decoupling domain from entity and beyond

Question

I am attempting to decouple my domain from my entity and opted to use AutoMapper to accomplish some of this. Perhaps this is an open question but I am wondering how people would go about decoupling these layers from each other. For example, I have the following:

public class A //Entity
{
    public int Id { get; set; }

    public string Name { get; set; }
}

public class B //Domain
{
    public string Name { get; set; }
}

I am wondering, truly decoupling the two would mean not presenting the property Id back to the domain? Essentially, my domain object will be consumed by the UI (MVC layer) and is it "correct" for the UI to have the concept of an ID, being able to manipulate and change it?

Thanks in advance, DS.

Answer 1

ID is also a DDD concept known as entity identifier. If the domain entity doesn't have an identifier, your ui and application are not able to manipulate them.

For example, I want to modify the booking contact name of an order with trackingId[123]. the ui need the identifier to fetch the order. The Order domain object is then reconsititute by mapping the order persistent entity(mapping all fields but id). The last thing is store the order(map domain to entity, but id is lost), how can I decide which order persistent entity to be updated if there is no identifier in Order domain object?

So the answer to "I am wondering, truly decoupling the two would mean not presenting the property Id back to the domain?" is no.

But some ids in persistent entities are not identical in domain objects, these ids could be skipped. same order example, if the application is built based on a legacy database, and the booking contact is an individual table from order table like:

create table t_order {
    tracking_id varchar2(255) pk,
    //other fields
};

create table t_order_booking_contact {
     tracking_id varchar2(255) pk,
     name varchar2(255),
     //other fields
}

But for some reasons, the BookingContact in domain model is a value object(no id needed). In this case, the trackingId in BookingContact persistent model could be skipped, the mapper and persistent component could use trackingId in Order persistent model instead.

For me, the truly decoupling the two would mean develop the domain models as what makes handle domain logic easily and develop the persistent models as what makes persistence easily. The mapper is used to fix the difference between them.

Answer 2

You know, the domain has entities too... You want he domain decoupled from anything else (persistenec, UI etc).

The UI has its own model (mainly the view models) who is created usually from the Domain model. Here is where the deocupling take place and you can use a service/mapper for that. in your case the view mode seems to be very similar to the domain model so you an use automapper to create the view model from a domain model.

is it "correct" for the UI to have the concept of an ID, being able to manipulate and change it?

It's correct for the UI to have ANY information it needs to do its job. However, the UI shouldn't change directly the domain model. The domain changes according to use cases (usually implemented in services/command handlers) and in 99.99% of cases I don't know why you would want to change the ID of a domain entity.