Implementing the User Registration Process

The Application Layer acts as the “public API” to the inner core. This boundary layer should accept requests and return responses, but it should also be agnostic to where those requests come from and where the responses are sent to.

Over the next couple of weeks we’re going to be looking at building out the Application Services for each of the main components of the application.

This week we’ll be looking at the User Registration process and how what we’ve built so far fits into the on-boarding flow for new users.

Recap of what we’ve built so far

It’s been a while since we looked at the user registration functionality of Cribbb, so I think a good place to start would be quick recap of how things stand right now.

In this case, I will have multiple layers of validation to ensure that the user has entered valid data and so if an Exception is thrown during this Domain Service, we know something has seriously went wrong.

The Exception in this example is a last line of protection against any funny business from the new user.

What is the role of the Application Service

So if the Domain Service is doing the heavy lifting of actually registering the new user, what is the role of the Application Service?

The Application Service actually has a very important role within the request lifecycle of registering a new user.

First, when the user is entering their email address and choosing a username we need to give immediate feedback as to whether the email and username have already been registered. It will be the Application Service that performs this check on the server side.

Secondly, when the user submits the registration form, the Application Service will act as a first line of defence to ensure that the correct data has been submitted.

Thirdly, when the User object is returned from the Domain Service it will be loaded with Domain Events that are ready to be dispatched. It is the Application Service’s job to dispatch those events. I’ve written previously on Domain Events in the article Implementing Domain Events.

And finally, the response from the application should be in a generic format. It will be the Application Service’s responsibility to return the response so that it is agnostic to the outside world.

Building the User Registration Application Service

So now that we are clear on what the responsibilities of the Application Service should be and how it should fit into the stack of the application, it’s now time to actually build it!

The first thing I’m going to do is to create a new Cribbb\Application\Identity namespace under the app/Cribbb directory.

Injecting the Domain Service

Next I can inject the Domain Service into the Application Service as a Dependency. This encapsulates the registration process and ensures that the Application Layer is dependent on the Domain Layer, and not the other way round:

Currently I’m only checking to ensure that the email and username are in the correct format, however at a later stage I will also add in Laravel’s unique rule to ensure that the email address or username have not already been registered.

Ideally I want to have a single endpoint for checking both the email address as well as the username. This endpoint should pass on the request details to the following method:

First we can reuse the validate() method from earlier to ensure that the data that has been passed is in fact valid. I don’t mind this double check because we can’t rely on the Javascript Ajax request.

Next we can pass the $email, $username and $password to the Domain Service. If everything goes smoothly, out should pop a new instance of User.

As I mentioned earlier, the User object will be loaded with Domain Events. At this point we can dispatch those Domain Events to notify the listeners that a new user has registered. I haven’t included that code yet as it’s something I’m going to come back to.

In this test I’m telling the mocked repository to expect certain method calls and then asserting that I’m returned an instance of User.

I’m undecided as to where I want to transform the $user object into a generic format (JSON). I can either do it inside this class, or inside of the Controller.

I like the idea of the Application returning a generic format, but I’m not sure if I want to give this class the extra responsibility.

I’ll sit on that decision for a while and implement that functionality in a later tutorial.

Conclusion

In today’s tutorial we took a proper first look at implementing an Application Service.

This Application Service serves two main purposes.

Firstly, it acts as an interface so we can make Ajax requests from the user registration sign up form. This allows us to check the server side validation stuff such as uniqueness (although I haven’t implemented that just yet).

Secondly, it also acts as at the “public API” endpoint for registering a new user. This Application Service can now be injected into a Controller or a Command Line tool to be used for registering new users into the application.

Next week we will continue to build out the Application Services layer of Cribbb.

This is a series of posts on building an entire Open Source application called Cribbb. All of the tutorials will be free to web, and all of the code is available on GitHub.