Sharing about Lucid Architecture x Laravel
- 2. Content ● About Lucid ● Concept ● Principles ● Benefits ● Demo ● References ● Q&A
- 3. About Lucid Lucid is a software architecture to build scalable Laravel projects. It incorporates Command Bus and Domain Driven Design at the core, upon which it builds a stack of directories and classes to organize business logic. It also derives from SOA (Service Oriented Architecture) the notion of encapsulating functionality within a service and enriches the concept with more than the service being a class.
- 4. Concept This architecture is in an amalgamation of best practices, design patterns and proven methods. ● Command Bus: to dispatch units of work. In Lucid terminology these units will be a Feature, Job or Operation. ● Domain Driven Design: to organize the units of work by categorizing them according to the topic they belong to. ● Service Oriented Architecture: to encapsulate and manage functionalities of the same purpose with their required resources (routes, controllers, views, database
- 5. Concept In a typical MVC application, Lucid will be the bond between the application’s entry points and the units that do the work, securing code form meandring in drastic directions:
- 6. Concept
- 7. Concept Domains Provide separation to categorize jobs and corresponding classes that belong to the same topic. A domain operates in isolation from other domains and exposes its functionalities to features and operations through Lucid jobs only. Consider the structure below for an example on what a domain may look like:
- 9. Concept Services Are directories rich in functionality, used to separate a Monolith into areas of focus in a multi-purpose application.
- 10. Concept Services
- 11. Concept Features Represent a human-readable application feature in a class. It contains the logic that implements the feature but with the least amount of detail, by running jobs from domains and operations at the application or service level. Serving the Feature class will be the only line in a controller’s method (in MVC), consequently achieving the thinnest form of controllers.
- 12. Concept Features
- 13. Concept Operations Their purpose is to increase the degree of code reusability by piecing jobs together to provide composite functionalities from across domains.
- 14. Concept Data For a scalable set of interconnected data elements, we’ve created a place for them in app/Data, because most likely over time writing the application there could develop a need for more than Models in data, such as Repositories, Value Objects, Collections and more.
- 15. Benefits Organization ● Predictable impact of changes on the system when reviewing code ● Reduced debugging time since we’re dividing our application into isolated areas of focus (divide and conquer) ● With Monolith, each of our services can have their own versioning system (e.g. Api service is at v1 while Chat is at v2.3 yet reside) yet reside in the same codebase
- 16. Benefits Reuse & Replace By dissecting our application into small building blocks of code - a.k.a units - we’ve instantly opened the door for a high degree of code sharing across the application with Data and Domains, as well as replaceability with the least amount of friction and technical debt.
- 17. Boundaries By setting boundaries you would’ve taken a step towards protecting application code from growing unbearably large and made it easier for new devs to onboard. Most importantly, that you’ve reduced technical debt to the minimum so that you don’t have to pay with bugs and sleepless nights; code doesn’t run on good intentions nor wishes. Benefits
- 18. Benefits Multitenancy When our application scales we’d typically have a bunch of instances of it running in different locations, at some point we would want to activate certain parts of our codebase in some areas and shut off others.
- 19. Benefits Multitenancy Here’s a humble example of running Api, Back Office and Web App instances of the same application, which in Lucid terminology are services that share functionality through data and domains:
- 21. References ● https://docs.lucidarch.dev/ ● https://github.com/lucidarch/lucid ● https://www.youtube.com/watch?v=wSnM4JkyxPw (The lucid architecture for building scalable applications - Laracon EU 2016)
- 22. Q&A
Editor's Notes
- #1: Reference document: https://docs.lucidarch.dev/concept/