DDD, creating an aggreagate from outside the application service layer

Question

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:

1. 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.
2. 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.

Answer 1

Generally, I'd say no. Aggregates should not leave your domain model boundary and any business logic related to creating that aggregate should reside within that aggregate.
I'd advise you to add a factory method to that aggregate class which takes in all the necessary parameters to create a new instance of that aggregate. If there's business logic related to that creation, it should reside in that factory method.
If you feel that you need way to many parameters for that factory method, then maybe that's a sign that that aggregate could be too big (maybe).

I don't really understand why you would create and then immediately return that instance though. Usually, you separate your reads and writes, because your read and write model are usually very different.