CODEWITHSUNDEEP
javaarchitecturedomain-driven-design
Aleksander Nuszel
Aleksander Nuszel

Reputation: 330

Communication between controller and facade, transformation request => dto

Well I divided my web application into modules. Each module communicates with others by Facade and that is the only entry point. Also controllers communicates with modules by facade.

Methods in facade take some DTO and do some business logic.

In 90 % cases request that comes to controller maps 1-1 facade method's DTO argument.

My question is : Is it good practice to use the same Class for taking request in controller and then using as DTO in facade?

Upvotes: 0

Views: 474

Answers (1)

priyanksriv
priyanksriv

Reputation: 1154

I won't say that there's an absolute correct way of doing this.

If your application is fairly simple, for instance, just database operations for creating and fetching data, simple data model and without a complex business logic, then it might be fine to use the same DTO. This scenario isn't mostly true.

But if your application is expected to handle a fair range of business "use cases", it's a good practice to keep your core domain layer objects separate from the ones that are used to interact with an external system such as an API or messaging queue.

If you take an example (a bit contrived use case to bring out the point I'm making):

Assume users can create customers in your application via a ReST endpoint now and there's a well defined request model:

class CustomerDTO {
  private String firstName;
  private String lastName;
  private String companyId;
  private String email;
  private List<String> subscriptions; // customers subscribe to services
}

Assume, your domain model:

class CustomerBO {
  private String name;   // firstName + lastName
  private String companyId;
  private String email;
  private List<String> subscriptions; // customers subscribe to services
}

Later, if you want to add the ability to create entities by reading them from a message queue or a CSV file - your application maybe a downstream system getting feed from another application. In this case, you have the following differences from the API use case:

  • each customer has just 1 subscription (always)
  • name is sent as a single field
  • there's no email, as these customers are not real human users (that is to say that no emails to be sent, no logins, etc)

So, your request model looks like this:

class FeedCustomerDTO {
  private String name;
  private String companyId;
  private String subscriptionId;
}

Now, application core just accepts CustomerBO. The API and Feed modules transform the request models to a consistent domain model. You can see that having a consistent CustomerBO across these two use cases helps you keep your application core clean and decoupled from the interactions.

Hope this makes sense and addresses your query.

Upvotes: 1

Related Questions