We need to send the email and password to the Application Service. There are many ways of doing such a thing from the client (HTML form, API client, or even the command line). We could just send standard parameters (email and password) through the method signature or build and send a data structure with this information. The latter approach, sending a DTO, brings some interesting features to the table. By sending an object, it'll be possible to serialize and queue it over a Command Bus. It'll also be possible to add type safety and some IDE help, too.
A DTO is a data structure that carries information between processes. Don't mistake it for a full-featured object. A DTO doesn't have any behavior except for storage and retrieval of its own data (accessors and mutators). DTOs are simple objects that shouldn't contain any business logic that would require testing.
As Vaughn Vernon says:
Application Service method signatures use only primitive types (int, strings, and so on.), and possibly DTOs. As an alternative to these approaches, however, a better approach may be to design Command objects instead. There is not necessarily a right or wrong way. It mostly depends on your tastes and goals.
The implementation for a DTO that holds the data required for the Application Service could be something like this:
namespace LwApplicationServiceUser;
class SignUpUserRequest
{
private $email;
private $password;
public function __construct($email, $password)
{
$this->email = $email;
$this->password = $password;
}
public function email()
{
return $this->email;
}
public function password()
{
return $this->password;
}
}
As you see, SignUpUserRequest has no behavior, only data. This could have come from an HTML form or an API endpoint, though we don't care which.