Laravel DDD - Laravel 中的 DDD 入门
在典型的 Laravel 应用程序中,我们非常习惯于以某种方式做事,正如他们所说的那样。然而,在应用程序的生命周期中,开始将代码拆分为域会更容易,这样我们就可以对代码进行逻辑分组。
我们的第一步是决定什么是我们的域代码和什么是我们的应用程序代码,最简单的方法是将任何可以从外部世界(如 web、cli 或 API)直接访问的内容保留在 App
命名空间。从这里我们可以开始定义我们的域边界,试着用更广泛的术语来思考这些问题,即「一篇文章必须在 Post 域中」,因为此时你没有解决任何问题。
让我们以一个机构网站为例,它有一个博客、作品和联系人表单。这不是一个复杂的构建,也不太可能过度到领域驱动设计 - 但这是一个我们可以很容易理解的东西,而不会因为应用程序逻辑而使 DDD 复杂化。我们可以首先将我们的领域分为:
- 博客
- 工作
- 沟通
我们的博客领域包含与博客帖子和类别有关的任何内容,我们的工作领域都是关于作品项目和研究案例,我们的沟通领域是表单提交和和任何需要外部通信,比如发送推文。
在我们的 composer.json
文件中,我们希望自动加载域的命名空间,确保我们可以轻松加载这些命名空间。 To为此,我们需要再添加几个命名空间:
"autoload": {
"psr-4": {
"App\\": "app/",
"Database\\Factories\\": "database/factories/",
"Database\\Seeders\\": "database/seeders/",
"Domains\\": "src/Domains",
"Infrastructure\\": "src/Infrastructure"
}
},
如你所见,我创建了 2 个新的顶级命名空间,Domains
和 Infrastructure
。 内部域是我们将保留所有特定于域的代码的地方,而内部基础设施是我通常会保留我在应用程序中绑定的所有接口/契约的地方。 这不是你可以做到这一点的唯一方法,但这是我发现的对自己有用的方法。
接下来我们要确保我们做的是为每个域创建一个服务提供者。 你可能会问自己为什么在这一点上,这是可以理解的,起初我不确定这一点。 然而,在花了一些时间使用它之后,它开始变得更有意义了。
服务提供者的示例如下所示:
<?php
declare(strict_types=1);
namespace Domains\Blogging\Providers;
use Illuminate\Support\ServiceProvider;
class BloggingServiceProvider extends ServiceProvider
{
public function boot(): void
{
// more will go here later
}
}
继续上面的例子,让我向你展示你的 config/app.php 提供者数组在它结束时应该有什么:
<?php
return [
'providers' => [
// Laravel 附带的所有其他组件
/*
* 域服务提供者
*/
Domains\Communication\Providers\CommunicationServiceProvider::class,
Domains\Blogging\Providers\BloggingServiceProvider::class,
Domains\Work\Providers\WorkServiceProvider::class,
]
];
这允许我们使用配置,只需通过评论我们的服务提供者来打开和关闭域。 它还允许我们轻松添加整个域。
现在我们已经通过 Composer 加载了我们的域,并且我们的 Laravel 应用程序知道每个域的服务提供者——我们已经准备好编写实际的域代码。
本文中的所有译文仅用于学习和交流目的,转载请务必注明文章译者、出处、和本文链接
我们的翻译工作遵照 CC 协议,如果我们的工作有侵犯到您的权益,请及时联系我们。
推荐文章: