How to create business layer objects out of input parameters properly? [closed]

I've been extracting the HTTP / web stuff out of my controllers for a while now, and couldn't look back. Essentially it leaves you with:

Use Case|Interactor|Controller - Function that, using your application's services, converts a business request into a business response. The key thing to note here is that you are dealing with single in/out message objects.

public function execute(RegistrationRequest $request)
{
    // some basic interactions between $request and your app
    // $request->getCredentials(), $request->getProfile(), etc.

    return new RegistrationResponse($accountInfo);
}

HTTP|CLI|etc. Translators - Function that builds the business request from the HTTP request, and converts the business response to a HTTP response. These wrap the use case or interactors to translate to the given communication channel. Again, single input object (HTTP request), single output object (HTTP response).

/**
 * Executes the usecase or controller in a web context
 * @param Http\Request $request
 * @return Http\Response
 */
public function handle(Http\Request $request)
{
    return $this->convertResponse($this->useCase->execute($this->convertRequest($request)));
}

/**
 * Converts a HTTP request into a RegistrationRequest
 * @param Http\Request $request
 * @return RegistrationRequest
 */
protected function convertRequest(Http\Request $request)
{
    return new RegistrationRequest(
        new UserCredentials(
            'username' => $request->post->get('username'),
            'password' => $request->post->get('password')
        ),
        new UserProfile(
            'name' => $request->post->get('name'),
            'gender' => $request->post->get('gender')
        )
    );
}

/**
 * Converts a RegistrationResponse into a Http\Response
 * @param RegistrationResponse $response
 * @return Http\Response
 */
protected function convertResponse(RegistrationResponse $response)
{
    return new Http\RedirectResponse($this->routing->generateUrl('/account'));
    // or 
    return new Http\Response($this->templating->render([
        'user' => $response->getUser()
    ]);
}

This way, you can ecapsulate some of your validation in your business objects rather than as form validation. You'd want to have a strategy on how you map various exception types into HTTP status codes, or into command line exit codes, etc.

This may be overkill based on your project, but I work with CLI and HTTP quite often so the added extraction is very handy. It also makes your HTTP code much simpler and less tied to any specific tools or frameworks.

Examples are in PHP, sorry if that is confusing at all. These should somewhat mimick the Entity Boundary Interactor or other similar architectural patterns.

I would rule out version 2 as it leads to cluttering the business object with form details. This is exactly why you have the request layer: to keep form and business object separated.

Versions 1 and 3 are pretty similar, except that 1 also requires the business logic to know about forms, even if only in a factory. So, unless you already have a business object factory that could help you here, I'd go for version 3.

(This all only makes limited sense as the amount of code is unknown etc.)

Btw, your "better version" is not necessarily better. In your first code sample you had the form fields spelled out twice. I'd put them in constants or something and use them. The second version hides those field names in the factory making it worse to understand where the business object input arguments a few lines down actually came from