With the emerging need for separation per concern, microservices emerged to be the trending progression of what used to be a monolithic application. Especially with Lucid, scale is one of the core concerns that a microservice is the natural progression of the architecture from its monolithic counterpart.

It is no coincidence that the different parts of a Lucid monolithic application are called a Service, for microservices are indeed the next progression when applications scale and reach that turning point. Having implemented your application using Lucid, the transition process will be logically simpler to think about and physically straight-forward to implement.

To see how it compares to the monolithic application and when to use which, check Monolith vs. Microservice

Check out my talk at LaraconEU 2016 where I introduce the concept and application of the Lucid architecture:

To get rolling, you need to create a new project using Composer:

composer create-project lucid-arch/laravel-microservice my-project

This project ships with the Lucid Console which provides an interactive user interface and a command line interface that are useful for scaffolding and exploring Services, Features and Jobs.

The lucid executable will be in vendor/bin. If you don't have ./vendor/bin/ as part of your PATH you will need to execute it using ./vendor/bin/lucid, otherwise add it with the following command to be able to simply call lucid:

export PATH="./vendor/bin:$PATH"

For a list of all the commands that are available run lucid or see the CLI Reference.

This is the Feature that we will be serving when someone visits our /users route.

lucid make:feature ListUsers

This Job will fetch the users from the database and will be used inside our Feature to serve them.

lucid make:job GetUsers user

Open the file that was generated at app/Domains/User/GetUsersJob.php and edit the handle method to this:

public function handle()
{
    return [
        ['name' => 'John Doe'],
        ['name' => 'Jane Doe'],
        ['name' => 'Tommy Atkins'],
    ];
}

In a real-world application you might want to fetch the users from a database, and here is the perfect place for that. Here's an example of fetching a list of users and providing the ability to specify the limit:

use App\Data\Models\User;

class GetUsersJob extends Job
{
    private $limit;

    public function __construct($limit = 25)
    {
        $this->limit = $limit;
    }

    public function handle(User $user)
    {
        return $user->take($this->limit)->get();
    }
}

NOTE: The namespace for models is [app namespace]\Data\Models

// ...
use App\Domains\User\GetUsersJob;
use App\Domains\Http\RespondWithJsonJob;
// ...
public function handle(Request $request)
{
    $users = $this->run(GetUsersJob::class);

    return $this->run(new RespondWithJsonJob($users));
}

The RespondWithJsonJob is one of the Jobs that were shipped with this project, it lives in the Http domain and is used to respond to a request in structured JSON format.

To be able to serve that Feature we need to create a route and a controller that does so.

Generate a plain controller with the following command

lucid make:controller user

And we will have our UserController generated in app/Http/Controllers/UserController.php which we will use to serve our Feature in its index method.

We just need to create a route that would delegate the request to our index method:

// ...
use App\Features\ListUsersFeature;
// ...
class UserController extends Controller
{
    public function index()
    {
        return $this->serve(ListUsersFeature::class);
    }
}

In routes/web.php add:

Route::get('/users', 'UserController@index');

That's it! Now serve the application with php artisan serve and visit https://localhost:8000/users

Lucid exposes event hooks that allow you to listen on each dispatched feature, operation or job. This is especially useful for tracing:

use Illuminate\Support\Facades\Event;
use Lucid\Foundation\Events\FeatureStarted;
use Lucid\Foundation\Events\OperationStarted;
use Lucid\Foundation\Events\JobStarted;

Event::listen(FeatureStarted::class, function (FeatureStarted $event) {
    // $event->name
    // $event->arguments
});

Event::listen(OperationStarted::class, function (OperationStarted $event) {
    // $event->name
    // $event->arguments
});

Event::listen(JobStarted::class, function (JobStarted $event) {
    // $event->name
    // $event->arguments
});

In the monolith Lucid application we have multiple services (i.e. Api, Web) and these typically will exist in src/Services/Api and src/Services/Web respectively. With the microservice the src does not exist, since it is intended to be one service serving a single purpose, the app directory will do. It will hold the following directories:

• Data For all your models, repositories and value objects.
• Domains Holds the Domains and their Jobs.
• Features The service's Features.

One other significant difference is in the location of tests:

It is always recommended that you start with a monolith and work on it until it gets so big that it is crucial to be dissected into single-purpose services (microservices). It would be challenging to be able to figure out the different services your application would need moving forward.

This project is also useful when you know for sure that your application will not have to deal with multiple Services but you would still like to use Lucid.