Ecosyste.ms: Awesome
An open API service indexing awesome lists of open source software.
https://github.com/artkonekt/concord
Laravel extension for building modular applications where modules are decoupled, re-usable and easily customizable
https://github.com/artkonekt/concord
laravel laravel-extension laravel5 modular modularity
Last synced: 27 days ago
JSON representation
Laravel extension for building modular applications where modules are decoupled, re-usable and easily customizable
- Host: GitHub
- URL: https://github.com/artkonekt/concord
- Owner: artkonekt
- License: mit
- Created: 2016-08-14T10:45:18.000Z (about 8 years ago)
- Default Branch: 1.x
- Last Pushed: 2024-05-16T05:59:12.000Z (6 months ago)
- Last Synced: 2024-09-28T19:02:35.022Z (about 1 month ago)
- Topics: laravel, laravel-extension, laravel5, modular, modularity
- Language: PHP
- Homepage:
- Size: 346 KB
- Stars: 206
- Watchers: 16
- Forks: 14
- Open Issues: 3
-
Metadata Files:
- Readme: README.md
- Changelog: Changelog.md
- License: LICENSE.md
Awesome Lists containing this project
README
# Concord
_Concord is a Laravel Extension that helps to build **Modules for Laravel Applications** on top of Laravel's built-in Service Providers._
[](https://github.com/artkonekt/concord/actions?query=workflow%3Atests)
[](https://packagist.org/packages/konekt/concord)
[](https://packagist.org/packages/konekt/concord)
[](https://styleci.io/repos/65661796)
[](https://scrutinizer-ci.com/g/artkonekt/concord/)
[](LICENSE.md)
Concord at first is a [Laravel package](https://laravel.com/docs/9.x/packages).
It also offers some conventions that help you to better structure complex systems.
## Version Compatibility
| Laravel | Concord |
|:--------|:-----------|
| 5.4 | 1.0 - 1.3 |
| 5.5 | 1.0 - 1.8 |
| 5.6 | 1.1 - 1.8 |
| 5.7 | 1.3 - 1.8 |
| 5.8 | 1.3 - 1.8 |
| 6.x | 1.4 - 1.10 |
| 7.x | 1.5 - 1.10 |
| 8.x | 1.8 - 1.11 |
| 9.x | 1.10.2+ |
| 10.x | 1.13+ |
| 11.x | 1.14+ |
## Basics
> Modular Architecture is exactly what you think it is - a way to manage the
> complexity of a problem by breaking them down to smaller manageable modules.
> -- [Param Rengaiah](https://medium.com/on-software-architecture/on-modular-architectures-53ec61f88ff4)
Concord itself (this library) manages the modules.
Concord [modules](https://konekt.dev/concord/1.8/modules) are isolated
fractions of the business logic, built around a single topic.
There are two kinds of modules from the usage perspective:
- in-app modules,
- external modules.
Concord is not aware of this difference at all, but they represent two different
approaches of modularization.
### In-app Modules
- They are part of the application's codebase;
- are located in `app/Modules/`;
- being decoupled is a less strict requirement;
- code reuse and customization is not an aspect.
### External Modules
- They are libraries,
- are typically managed with composer, thus they live in the `vendor/` folder;
- should be as decoupled as possible;
- contain basic or boilerplate functionality for applications;
- they are designed to be used by multiple, different applications;
- their behavior is subject to customization in the application.
Either module types are always coupled to Laravel and Concord;
## Installation
Refer to the [Installation Section](https://konekt.dev/concord/1.8/installation) of the Documentation.
## Create Your First Module
```
php artisan make:module ShinyModule
```
This will create a very basic in-app module in the `app/Modules/ShinyModule` folder.
In order to activate the module add it to the `config/concord.php` file:
```php
return [
'modules' => [
App\Modules\ShinyModule\Providers\ModuleServiceProvider::class
]
];
```
## Documenatation
See the [Concord Documentation](https://konekt.dev/concord/1.x) for all the
nasty details ;)
## Plans For Version 2.0
- Artisan Console command names will be de-branded (eg. `concord:modules` -> `module:list`)
- The central `config/concord.php` file will be eliminated, or split:
- modules can specify their own config file name (like normal Laravel packages);
- therefore several modules can share config files (see vanilo.php);
- if we keep concord.php, then it'll contain concord specific settings.
- Modules will be loaded as normal packages, using auto-discovery instead of listing modules with concord.
- Custom names for service providers eg. CartServiceProvider instead of ModuleServiceProvider.
- Question to the prior item is how to do the same with in-app modules.
- Re-think the concept of boxes vs. modules.
- Remove surplus items from Documentation.
- Remove helpers (?).
- Remove custom view namespace support.
- Will we ever use Controller overriding?
- Add make:request, make:model, make:enum commands that scaffold with interface, proxy etc.
- Fix AddressType -> address_type kind of style problem in route parameters