Table of Contents
Framework-agnostic application: Overview
No matter the tools you use, you may create a framework-agnostic application. Domain-Driven Design (DDD) — hexagonal design and similar patterns – has recently been a hot topic among PHP developers. Their main purpose is to decouple business logic from a framework, storage, and code. I’d like to expand on this issue and demonstrate how to segregate domain-related information from all boilerplate required to get everything up and to run. This would most likely assist others (including myself) in the beginning to write reusable extensions for Phalcon, something this amazing framework now lacks. There’s no need for bundles or service providers for Composer/Packagist; they’re all just shortcuts for DI containers anyhow, and they bind your package to a framework. Make something universally useful and teach others how to use it effectively with a DI container.
That is the hypothesis. When you need to accomplish something tangible, you choose an ORM as a minimum right away, so it’s immediately tied to something other than PHP. If you try to do it without using a framework, you’ll wind up with many heavy abstractions and a lot of design headaches.
Building a framework-agnostic application in PHP for domain.
- This model suggests crucial properties like password or emails.
- The RunResult and RunParticipation classes which relate our runner to runs and their outcomes.
Inherits DomainException rather than directly extending PHP’s Exception.
We just emphasis on the most critical aspects!
The crucial domain layer is already covered. We’ll utilise a command bus in this layer, therefore there will be a class for each application operation. We have a very simple Command class in this pattern that contains data introduced by a system operator.
Let’s discover the runner’s enrolment.
Eloquent maps these properties via magic getters/setters, so having these properties explicitly defined would prevent Eloquent from working.
There’s only one challenge now: how can you connect these two classes that are so dissimilar? Extending may not be a good idea because they are so dissimilar, especially if the storage model extends ORM’s Model class. We do, however, have a second choice. Let’s make a class that can translate between these two models in both directions.
RunParticipation: Eloquent model
Framework-agnostic app integration
Let’s link everything together with Laravel now. The application layer is where we connect.
Connect Eloquent and Doctrine to create a framework-independent app with storage.
The entities of doctrine aren’t at all self-contained. To maintain relationships between classes, you must utilise the ORM’s ArrayCollection class.
Here’s the example of RunParticipation entity:
The last thing to notice in the sample below is that read/write repositories are shown.
Comments are closed.