I have a service(webservice) that is used to access to the domain logic. One of the methods of the webservice is createFoo, where Foo is my aggregate. So the class that implements the webservice's method calls my application service that contains the createFoo method which is responsible of doing some stuff and persisting the new Foo instance.
This new Foo instance the is returned by the application service to the class that implements the web service's method. Finally, the Foo instance is converted to something like FooWsResponse and then the web service returns the FooWsResponse instance.
Right now all this is more or less implemented like this:
public class CreateFooService{
private FooService appService;
private Converter<Foo, FooWsResponse> converter;
public FooWsResponse createFoo(CreateFooParams params){
Foo foo = FooFactory.createFoo(params);
foo = appService.createFoo(foo);
return converter.converter(foo);
}
}
The problem with the code above is that the Application Service method is misleading because is not creating a Foo instance, is only working on the domain logic associated to the creation of Foo and persisting the instance.
So, the things that I want to know are:
- Is it ok create the aggregate outside the service layer?. I know that I can pass the CreateFooParams as parameter appService.createFoo but I don't want to do this because my service layer will be coupled to the web service framework. Also, I don't want to pass all the properties of the class CreateFooParams as parameters of appService.createFoo because I will end with a method with 15 parameters!. Finally, creating the Foo instance before calling appService.createFoo method but now the method's name is not accurate and also all clients of my appService should need to create how to create an instance of Foo to pass it as parameter of appService.createFoo which is very bad and may lead to many issues.
- Should I create a FooDto that receives all the data of CreateFooParams and pass it to appService.createFoo method?. This looks like a better option but having 3 different classes with almost the same properties feels very redundant
I want to know what is the right thing to do according to the DDD guidelines.
Thanks for your help.