Send a domain object as a parameter or send an object identifier as a parameter in applications

Question

when using a domain-driven project, is it better for the methods of your services to receive the object as a parameter or the identifier of your object as a parameter so that you can get the object inside the method using the repository?

eg:

public void Apply(Job job, User user) 

against

 public void Apply(int jobId, int userId) 

Answer 1

DDD is a mapping of your customer’s vocabulary to your design. Your client (hopefully) is talking about users applying for jobs, not an integer identifier associated with another integer identifier. Try to stay as close as possible to the real world if this does not become a burden.

By transferring the entire entity, you can immediately use the entity without first creating it.

Therefore, stick to entities if you do not have a situation where you often only have an ID. This usually happens when you are dealing with external systems such as web services. In this case, you can create a method overload that takes an identifier. This overload must verify the identifier, build the object, and invoke the overload that takes the object.

 public void Apply(int jobId, int userId) { // Validate the IDs. // Construct the entities. var job = ...; var user = ...; // Call the 'proper' overload. Apply(job, user); } public void Apply(Job job, User user) { // Actual business logic belongs here. } 

Again: try to avoid such overloads as much as possible, unless you are dealing with external systems that return only IDs.

In terms of coding, entities are also better than integers. An integer can be any integer value, so you have to check it wherever you use it. Your factories are responsible for creating the right objects, and your (domain) logic should keep your entities in an acceptable state. Thus, the use of the object is completely safe and does not require much verification.

Answer 2

Depending on where the Application Service is located:

If your Service is running in the same AppDomain (i.e. you are calling it from the same executable), then passing the object is ideal. The service can easily access other objects in the objects graph.

If your Service is running in an AppDomain application (for example, behind a WebService or other remote location), you must use an identifier. The Service will then load the corresponding object from the persistence store before working with it.

If you try to send objects by wire, you are likely to encounter the problems described here .

Hope this helps.

Answer 3

If you submit an object, you create a dependency between the service and the object. One of the advantages of using services is the use of facades to reduce the graph of dependency between classes and reduce design complexity. It is better to use primitive types, structures, enumerations in service contracts, but when working with a large number of method parameters, you can encapsulate them in an object, but in this case it will not be an DTO entity.

Answer 4

I use ViewModel to transfer "flat objects" to / from the application service. I also use the Message Message template to communicate with the application service. The application service uses extension methods for business units like this:

 public BusinessEntityViewModel ConvertToViewModel(this BusinessEntity businessEntity) { BusinessEntityViewModel bevm = new BusinessEntityViewModel{ Id = businessEntity.Id, ...} return bevm; } 

Answer 5

In my understanding, the only difference is what Domain does with User and Job to perform the Apply operation. If the ID is enough, then it’s normal to leave only the ID there.