nWidart/laravel-modules作者对多模块开发的官方解读

About the Author

My name is Nicolas Widart, and I'm a flexible enthusiastic software engineer and consultant. I'm a Laravel framework specialist; an open-source contributor and always on the lookout for new technologies and paradigm changes.

关于作者

我的名字是Nicolas Widart，我是一个灵活热情的软件工程师和顾问。我是一个Laravel框架专家；一个开源的贡献者，并且总是在寻找新的技术和范式的变化。

Plugin Interpretation

Let me start by saying Laravel is an amazing framework. However when it comes to writing more complex and bigger applications, I find the default structure laravel comes with cumbersome and not ideal.

插件解读

让我先说说Laravel是一个了不起的框架。然而，当它涉及到编写更复杂和更大的应用程序时，我发现Laravel的默认结构是很麻烦的，并不理想。

The way the default laravel installation comes with is basically all the application logic inside an app/ folder. This works, but I would not suggest going this route.

默认的laravel安装方式基本上是将所有的应用逻辑放在一个app/文件夹里。这样做可以, 但我不建议走这条路。

Just imagine having a medium sized applicated where everything is in the app/ folder, worse, every model is in the root of the app folder! At some point you will spend a lot of time looking for things because everything is bunched together.

试想一下，如果有一个中等规模的应用程序，所有的东西都在app/文件夹里，更糟糕的是，每个模型都在app文件夹的根部！你会花很多时间寻找东西，因为所有的东西都在一起。在某些时候，你会花很多时间来寻找东西，因为所有东西都在一起。

Enter the modular world
This is what being modular is trying to resolve. You split of the business logic into different parts, which belongs together. If you're into Domain Driven Design, you can consider a module an aggregate.

进入模块化的世界
这就是模块化所要解决的问题。你把业务逻辑分成不同的部分，这些部分属于一起。如果你喜欢领域驱动设计，你可以把一个模块看作是一个集合体。

Every module has its own routes/controllers/models/views/business logic/etc. Meaning every module contains a group of classes that all are related to each other in some way.

每个模块都有自己的路由/控制器/模型/视图/业务逻辑/等等。这意味着每个模块都包含一组类，它们都以某种方式相互关联。

Example

Consider an application where you'd have products and a shopping cart. To keep it simple.

You would have something like this:

举例
考虑一个应用程序，你有产品和购物车。为了简单起见。

你会有这样的东西。

app/
    - Http
        - Controllers
            - Admin
                - ProductsController
                - ProductCategoryController
                - OrderController
                - OrderStatusController
            - Frontend
                - ProductsController
                - CartController
                - CartAddressController
                - CartPaymentController
                - CartReviewController
                - CartSuccessController
                - ...
        - Requests
	        - CreateProductRequest
	        - UpdateProductRequest
	        - CreateProductCategoryRequest
	        - UpdateProductCategoryRequest
	        - CreateAddressRequest
	        - UpdateAddressRequest
	        - ...
        - Middleware
	        - HasCartItem
        - routes.php
    - Models
	    - Product
	    - ProductCategory
	    - Cart
	    - CartItem
	    - User
	    - UserAddress
	    - Order

As you can see I'm leaving a lot of classes out or this would be a lot bigger. We're not even covering repositories, views, service classes and more. Even this few classes already show that application is becoming a mess. Applications also have more than just products and carts, so the mess would be even worse.

Now lets see what this could look like with a modular approach.

正如你所看到的，我漏掉了很多类，否则这将是一个很大的问题。我们甚至还没有包括存储库、视图、服务类和更多。即使是这几个类也已经表明，应用程序正在变得一团糟。应用程序也不仅仅有产品和购物车，所以这个混乱的局面会更加严重。

现在让我们看看采用模块化的方法会是什么样子。

Modules/
    - Cart
        - Http
            - Controllers
                - Frontend
                    - CartController
                    - CartAddressController
                    - CartPaymentController
                    - CartReviewController
                    - CartSuccessController
            - Requests
                - CreateAddressRequest
                - UpdateAddressRequest
            - Middleware
                - HasCartItem
            - adminRoutes.php
            - frontendRoutes.php
        - Models
            - Cart
            - CartItem
        - Repositories
        - resources
            - lang
            - views
    - Product
        - Http
            - Controllers
                - Admin
                    - ProductController
                    - ProductCategoryController
                - Frontend
                    - ProductController
            - adminRoutes.php
            - frontendRoutes.php
            - Requests
                - CreateProductRequest
                - UpdateProductRequest
                - CreateProductCategoryRequest
                - UpdateProductCategoryRequest
        - Models
            - Product
            - ProductCategory
        - Repositories
        - resources
            - lang
            - views

With this structure, everything that belongs together is grouped into one namespace. This also means that you don't end up with one huge routes file for instance.

When you need to find something, you directly know where to search, in which folder you can dig through.

Granted, there are more folders, but it has the advantage of being clear at a birds eye view. Uncle Bob has a good video about architecture on why keeping everything in app/ isn't a good idea.

有了这种结构，所有属于一起的东西都被归入一个命名空间。这也意味着，你最终不会有一个巨大的路线文件，例如。

当你需要找东西的时候，你直接知道在哪里搜索，在哪个文件夹里可以挖掘。

当然，有更多的文件夹，但它的优点是在鸟瞰时很清楚。鲍勃叔叔有一个关于架构的好视频，说明为什么把所有东西都放在app/里不是一个好主意。

Modules in Laravel

Now you must be thinking how do I implement this in laravel ? At its basics it's fairly easy, you can just autoload the Modules folder using PSR-4 and be done with it.

However that leaves more work to you to register the custom view/lang/config namespaces, being able to have migrations in each module and run migrations of an individual module. Having frontend assets per module, and having a quick way to publish them to the public/ directory. Also an easy way to access to correct asset based on a given module name. etc. etc.

TL;DR, there is a lot more than just PSR-4 autoloading if you want to be productive using this method, and want to have a lot of convience methods availabel to you.

That's where the package Laravel-modules comes in.

This package will give you the ability to have custom namespaces for views, config, and languages. Handling migrations/seeds per module. Assets management per module. Helper convience methods. And so much more.

This package is what AsgardCMS uses behind the scenes to achieve its modular approach.

Laravel的模块
现在你一定在想我如何在Laravel中实现这个功能? 基本上是相当简单的, 你可以使用PSR-4自动加载模块文件夹并完成它.

然而，这留下了更多的工作给你来注册自定义view/lang/config命名空间，能够在每个模块中进行迁移，运行单个模块的迁移。每个模块都有前端资产，并且有快速的方法将它们发布到公共/目录中。还有一种简单的方法可以根据给定的模块名称访问正确的资产，等等。

TL;DR, 如果你想使用这种方法来提高生产力, 并希望有很多方便的方法可以使用, 那就不仅仅是PSR-4自动加载了.

这就是Laravel-modules包的用处.

这个包会让你有能力为视图, 配置, 和语言提供自定义命名空间. 处理每个模块的迁移/种子。每个模块的资产管理. 帮助性的便利方法. 还有更多。

这个包是AsgardCMS为实现其模块化方法而在幕后使用的。

One more thing

To top it all of, every module can be considered as a composer package. Meaning you can re-use your modules on other projects and handle its versioning easily.

This means that on top of having a maintainable architecture, you also save time be being able to re-use modules you created for other projects.

Convinced ? Check out the Laravel-modules package and give it a try.

还有一件事
最重要的是，每个模块都可以被看作是一个组合包。这意味着你可以在其他项目中重复使用你的模块，并轻松处理其版本。

这意味着，除了拥有一个可维护的架构外，你还可以在其他项目中重复使用你创建的模块，从而节省时间。

确信吗? 看看Laravel-modules包并试一试吧.