事件溯源是一個在過去幾年 PHP 社群越來越流行的術語,但對許多開發人員來說仍然是個謎。這些問題總是如何以及為什麼,當然這是可以理解的。本教學的目的是透過一個實際的方式不僅僅是幫你理解什麼是事件溯源,同樣也會讓你知道什麼時候你可能會想使用它。
在傳統應用程式中,我們的應用程式狀態直接表示在我們所連接的資料庫中。我們不能夠完全理解它是怎麼到那裡的。我們只知道他是這樣的。我們可以透過一些方法來進一步理解一點,使用審計模型更改的工具,這樣我們就可以看到更改了什麼,是誰做的。這也是朝著正確方向邁出的一步。然而,我們仍然不明白這個關鍵的問題。 【相關推薦:laravel影片教學】
為什麼?為什麼這個模型改變了?這改變的目的是什麼?
這就是事件溯源發揮作用的地方,它保留了應用程式狀態發生了什麼以及為什麼發生變化的歷史視圖。事件溯源允許你根據過去做出決定,從而你能夠產生報告。但在基本層面,他能讓你知道為什麼這個應用的狀態改變了,這是透過事件完成的。
我將會建立一個基礎的 Laravel 專案來引導你理解它是如何運作的。我們會將這個應用程式建構的簡單些,以便你能理解時間溯源的邏輯而不是對於應用程式邏輯困惑。我們正在建立一個可以慶祝團隊成員的應用程式。這就對了。簡單而易於理解。我們與用戶有團隊,我們希望能夠在團隊中公開慶祝一些事情。
我們將新建一個 Laravel 項目,但我將使用 Jetstream,因為我想啟用身份驗證和團隊結構和功能。一旦你創建了這個專案, 請在你的IDE中打開它。 (這裡的正確答案當然是 PHPStorm ), 現在我們已經準備好在 Laravel 深入事件溯源。
我們希望為應用程式建立一個附加模型,這是唯一的一個。這是一個Celebration
模型,你可以使用以下的Artisan指令來建立它:
php artisan make:model Celebration -m
修改你的遷移檔案up 方法,它看起來應該像這樣:
public function up(): void { Schema::create('celebrations', static function (Blueprint $table): void { $table->id(); $table->string('reason'); $table->text('message')->nullable(); $table ->foreignId('user_id') ->index() ->constrained() ->cascadeOnDelete(); $table ->foreignId('sender_id') ->index() ->constrained('users') ->cascadeOnDelete(); $table ->foreignId('team_id') ->index() ->constrained() ->cascadeOnDelete(); $table->timestamps(); }); }
我們有一個慶祝的原因 reason
,一個簡單的句子,然後是我們可能希望與慶祝活動發送的可選消 message
。除此之外,我們有三個關係,正在慶祝的用戶,發送慶祝的用戶,以及他們所在的團隊。使用 Jetstream,一個使用者可以屬於多個團隊,並且可能存在兩個使用者在同一個團隊中的情況
,我們要確保我們在正確的團隊中公開慶祝他們。
一旦我們有了這個設定,讓我們看看模型本身:
declare(strict_types=1); namespace App\Models; use Illuminate\Database\Eloquent\Factories\HasFactory; use Illuminate\Database\Eloquent\Model; use Illuminate\Database\Eloquent\Relations\BelongsTo; use Illuminate\Database\Eloquent\Relations\HasMany; final class Celebration extends Model { use HasFactory; protected $fillable = [ 'reason', 'message', 'user_id', 'sender_id', 'team_id', ]; public function user(): BelongsTo { return $this->belongsTo( related: User::class, foreignKey: 'user_id', ); } public function sender(): BelongsTo { return $this->belongsTo( related: User::class, foreignKey: 'sender_id', ); } public function team(): BelongsTo { return $this->belongsTo( related: Team::class, foreignKey: 'team_id', ); } }
我們可以將這些關係映射到其他相關的模型。儘管,預設情況下,我會將關聯關係的另一端添加到每個模型中,使它們的關聯關係更加清楚,無論它是否嚴格需要這些關聯關係。這是我養成的習慣,為了幫助他人理解模型本身。
現在我們有了從模型視角創建的我們的應用基礎。我想我們需要一些安裝一些對我們有幫助的軟體包(依賴)。對於我的應用,我使用 Laravel Livewire 來控制 UI 。但我並不會在本教學中詳細介紹這個包,因為我想確保我能專注於講事件溯源這個方面。
與我創建的大多數專案一樣,無論大小,我都為應用程式採用了模組化佈局——一個領域驅動模型設計 ( Domain Driven Design ) 方法。這只是我所做的事情,不要覺得你自己必須遵循這個,因為它是非常主觀的。
我的下一步是設定我的網域,對於這個演示,我只有一個網域:文化。在文化中,我為我可能需要的一切創造了名稱空間。但我會經歷它,這樣你就明白了過程
第一步是安裝一個軟體包,使我能夠在Laravel中使用事件來源。為此,我使用了一個 Spatie package套件,它為我做了大量的後台工作
composer require spatie/laravel-event-sourcing
安裝後,請確保按照套件的安裝說明進行操作,因為配置和遷移需要發布。正確安裝後,執行遷移,使資料庫處於正確狀態。
php artisan migrate
現在我們可以開始思考我們要如何實現事件溯源。你可以透過兩種方式實現這一點:投影機來投影你的狀態或聚合。
Projector 是一个位于你的应用程序中并处理你调度的事件的类。然后,这些将更改你的应用程序的状态。这不仅仅是简单地更新你的数据库。它位于中间,捕获一个事件,存储它,然后进行所需的更改 —— 然后 “投射” 应用程序的新状态
另一种方法,我的首选方法,聚合 - 这些是像投影仪一样为你处理应用程序状态的类。我们不是在我们的应用程序中自己触发事件,而是将其留给聚合为我们做。把它想象成一个中继,你要求中继做某事,它会为你处理。
在我们创建第一个聚合之前,需要在后台做一些工作。我非常喜欢为每个聚合创建一个事件存储,以便查询更快,并且该存储不会很快填满。这在包文档中进行了解释,但我将亲自引导你完成它,因为它在文档中并不是最清楚的。
第一步是创建模型和迁移,因为你将来需要一种方法来查询它以进行报告等。运行以下 artisan 命令来创建这些:
php artisan make:model CelebrationStoredEvent -m
以下代码是你在 up 方法中进行迁移所需的代码:
public function up(): void { Schema::create('celebration_stored_events', static function (Blueprint $table): void { $table->id(); $table->uuid('aggregate_uuid')->nullable()->unique(); $table ->unsignedBigInteger('aggregate_version') ->nullable() ->unique(); $table->integer('event_version')->default(1); $table->string('event_class'); $table->json('event_properties'); $table->json('meta_data'); $table->timestamp('created_at'); $table->index('event_class'); $table->index('aggregate_uuid'); }); }
如你所见,我们为我们的活动收集了大量数据。现在模型要简单得多。它应该如下所示:
declare(strict_types=1); namespace App\Models; use Spatie\EventSourcing\StoredEvents\Models\EloquentStoredEvent; final class CelebrationStoredEvent extends EloquentStoredEvent { public $table = 'celebration_stored_events'; }
当我们扩展 EloquentStoredEvent
模型时,我们需要做的就是改变它正在查看的表。模型的其余功能已经在父级上到位。
要使用这些模型,你必须创建一个存储库来查询事件。这是一个非常简单的存储库 —— 然而,这是一个重要的步骤。我将我的添加到我的域代码中,位于 src/Domains/Culture/Repositories/
下,但您可以随意添加对您最有意义的位置:
declare(strict_types=1); namespace Domains\Culture\Repositories; use App\Models\CelebrationStoredEvent; use Spatie\EventSourcing\StoredEvents\Repositories\EloquentStoredEventRepository; final class CelebrationStoredEventsRepository extends EloquentStoredEventRepository { public function __construct( protected string $storedEventModel = CelebrationStoredEvent::class, ) { parent::__construct(); } }
既然我们有了存储事件和查询它们的方法,我们可以继续我们的聚合本身。同样,我将我的存储在我的域中,但可以随意将你的存储在你的应用程序上下文中。
declare(strict_types=1); namespace Domains\Culture\Aggregates; use Domains\Culture\Repositories\CelebrationStoredEventsRepository; use Spatie\EventSourcing\AggregateRoots\AggregateRoot; use Spatie\EventSourcing\StoredEvents\Repositories\StoredEventRepository; final class CelebrationAggregateRoot extends AggregateRoot { protected function getStoredEventRepository(): StoredEventRepository { return app()->make( abstract: CelebrationStoredEventsRepository::class, ); } }
到目前为止,除了为我们连接到正确的事件存储之外,此聚合不会执行任何操作。要让它开始跟踪事件,我们首先需要创建它们。但在此之前,我们需要停下来想一想。我们希望在活动中存储哪些数据?我们想要存储我们需要的每一个属性吗?或者我们是否希望存储一个数组,就像它来自一个表单一样?我两种方法都不用,因为为什么要保持简单呢?我在所有事件中使用数据传输对象,以确保始终维护上下文并始终提供类型安全。
我构建了一个软件包,让我做这件事更容易。可以通过以下 Composer 命令安装它:
composer require juststeveking/laravel-data-object-tools
和以前一样, 我默认将我的数据对象保存在我的领域, 但你可以添加到对你最有意义的地方。 我创建了一个名为 Celebration
的数据对象,可以传递给事件和聚合器:
declare(strict_types=1); namespace Domains\Culture\DataObjects; use JustSteveKing\DataObjects\Contracts\DataObjectContract; final class Celebration implements DataObjectContract { public function __construct( private readonly string $reason, private readonly string $message, private readonly int $user, private readonly int $sender, private readonly int $team, ) {} public function userID(): int { return $this->user; } public function senderID(): int { return $this->sender; } public function teamUD(): int { return $this->team; } public function toArray(): array { return [ 'reason' => $this->reason, 'message' => $this->message, 'user_id' => $this->user, 'sender_id' => $this->sender, 'team_id' => $this->team, ]; } }
当我升级到 PHP 8.2 时,这会容易得多,因为我可以创建只读类 - 是的,我的包已经支持它们。
现在我们有了我们的数据对象。我们可以回到我们想要存储的事件。我已经调用了我的CelebrationWasCreated
,因为事件名称应该总是过去时。让我们看看这个事件:
declare(strict_types=1); namespace Domains\Culture\Events; use Domains\Culture\DataObjects\Celebration; use Spatie\EventSourcing\StoredEvents\ShouldBeStored; final class CelebrationWasCreated extends ShouldBeStored { public function __construct( public readonly Celebration $celebration, ) {} }
因为我们使用的是数据对象,所以我们的类保持干净。所以,现在我们有了一个事件——以及一个可以发送的数据对象,我们需要考虑如何触发它。这让我们回到了聚合本身,所以让我们在聚合上创建一个可以用于此目的的方法:
declare(strict_types=1); namespace Domains\Culture\Aggregates; use Domains\Culture\DataObjects\Celebration; use Domains\Culture\Events\CelebrationWasCreated; use Domains\Culture\Repositories\CelebrationStoredEventsRepository; use Spatie\EventSourcing\AggregateRoots\AggregateRoot; use Spatie\EventSourcing\StoredEvents\Repositories\StoredEventRepository; final class CelebrationAggregateRoot extends AggregateRoot { protected function getStoredEventRepository(): StoredEventRepository { return app()->make( abstract: CelebrationStoredEventsRepository::class, ); } public function createCelebration(Celebration $celebration): CelebrationAggregateRoot { $this->recordThat( domainEvent: new CelebrationWasCreated( celebration: $celebration, ), ); return $this; } }
在这一点上,我们有一种方法来要求一个类记录事件。但是,这一事件还不会持续下去 —— 那是以后的事。此外,我们不会以任何方式改变应用程序的状态。那么,我们该如何做这项活动采购工作呢?这一部分是关于 Livewire 中的实现的,我现在将向你介绍它。
我喜欢通过调度一个事件来管理这个过程,因为它更高效。如果你考虑如何与应用程序交互,你可以从 Web 访问它,通过 API 端点发送请求,或者发生 CLI 命令可能运行的事件 —— 可能是一个 Cron 作业。在所有这些方法中,通常,你需要即时响应,或者至少您不想等待。我将在我的 Livewire 组件上向你展示我为此使用的方法:
public function celebrate(): void { $this->validate(); dispatch(new TeamMemberCelebration( celebration: Hydrator::fill( class: Celebration::class, properties: [ 'reason' => $this->reason, 'message' => $this->content, 'user' => $this->identifier, 'sender' => auth()->id(), 'team' => auth()->user()->current_team_id, ] ), )); $this->closeModal(); }
在这一点上,我们有一种方法来要求一个类记录事件。但是,这一事件还不会持续下去 —— 那是以后的事。此外,我们不会以任何方式改变应用程序的状态。那么,我们该如何做这项活动采购工作呢?这一部分是关于 Livewire 中的实现的,我现在将向你介绍它。
我喜欢通过调度一个事件来管理这个过程,因为它更高效。如果你考虑如何与应用程序交互,你可以从 Web 访问它,通过 API 端点发送请求,或者发生 CLI 命令可能运行的事件 —— 可能是一个 Cron 作业。在所有这些方法中,通常,你需要即时响应,或者至少你不想等待。我将在我的 Livewire 组件上向你展示我为此使用的方法:
public function celebrate(): void { $this->validate(); dispatch(new TeamMemberCelebration( celebration: Hydrator::fill( class: Celebration::class, properties: [ 'reason' => $this->reason, 'message' => $this->content, 'user' => $this->identifier, 'sender' => auth()->id(), 'team' => auth()->user()->current_team_id, ] ), )); $this->closeModal(); }
当我验证来自组件的用户输入,可以分派处理一个新的作业,然后结束这个流程。我使用我的包将一个新的数据对象传递给作业。它有一个 Facade,可以让我用一系列属性来为类添加——到目前为止它工作得很好。那么这是怎么实现的呢?让我们来看看。
declare(strict_types=1); namespace App\Jobs\Team; use Domains\Culture\Aggregates\CelebrationAggregateRoot; use Domains\Culture\DataObjects\Celebration; use Illuminate\Bus\Queueable; use Illuminate\Contracts\Queue\ShouldQueue; use Illuminate\Foundation\Bus\Dispatchable; use Illuminate\Queue\InteractsWithQueue; use Illuminate\Queue\SerializesModels; use Illuminate\Support\Str; final class TeamMemberCelebration implements ShouldQueue { use Queueable; use Dispatchable; use SerializesModels; use InteractsWithQueue; public function __construct( public readonly Celebration $celebration, ) {} public function handle(): void { CelebrationAggregateRoot::retrieve( uuid: Str::uuid()->toString(), )->createCelebration( celebration: $this->celebration, )->persist(); } }
我们的工作将数据对象接受到它的构造函数中,然后在处理它时存储它。处理作业时,它使用 CelebrationAggregateRoot
按 UUID 检索聚合,然后调用我们之前创建的 createCelebration
方法。在它调用了这个方法之后 - 它在聚合本身上调用了 persist
。这就是将为我们存储事件的内容。但是,同样,我们还没有改变我们的应用程序状态。我们所做的只是存储一个不相关的事件而不是创建我们想要创建的庆祝活动?那么我们缺少什么?
我们的事件也需要处理。在另一种方法中,我们使用投影仪来处理我们的事件,但我们必须手动调用它们。这是一个类似的过程,但是我们的聚合正在触发事件,我们仍然需要一个投影仪来处理事件并改变我们的应用程序状态。
让我们创建我们的投影仪,我称之为处理程序 —— 因为它们处理事件。但我会让你决定如何命名你的。
declare(strict_types=1); namespace Domains\Culture\Handlers; use Domains\Culture\Events\CelebrationWasCreated; use Spatie\EventSourcing\EventHandlers\Projectors\Projector; use Infrastructure\Culture\Actions\CreateNewCelebrationContract; final class CelebrationHandler extends Projector { public function __construct( public readonly CreateNewCelebrationContract $action, ) {} public function onCelebrationWasCreated(CelebrationWasCreated $event): void { $this->action->handle( celebration: $event->celebration, ); } }
我们的投影机 / 处理程序,无论你选择如何称呼它,都将从容器中为我们解析 - 然后它将寻找一个以 on
为前缀的方法,后跟事件名称本身。所以在我们的例子中,onCelebrationWasCreated
。在我的示例中,我使用一个动作来执行事件中的实际逻辑 - 单个类执行一项可以轻松伪造或替换的工作。所以再一次,我们把树追到下一个班级。动作,这对我来说是这样的:
declare(strict_types=1); namespace Domains\Culture\Actions; use App\Models\Celebration; use Domains\Culture\DataObjects\Celebration as CelebrationObject; use Illuminate\Database\Eloquent\Model; use Infrastructure\Culture\Actions\CreateNewCelebrationContract; final class CreateNewCelebration implements CreateNewCelebrationContract { public function handle(CelebrationObject $celebration): Model|Celebration { return Celebration::query()->create( attributes: $celebration->toArray(), ); } }
这是当前执行的操作。如你所见,我的操作类本身实现了一个合同 / 接口。这意味着我将接口绑定到我的服务提供者中的特定实现。这使我可以轻松地创建测试替身 / 模拟 / 替代方法,而不会对需要执行的实际操作产生连锁反应。这不是严格意义上的事件溯源,而是通用编程。我们确实拥有的一个好处是我们的投影仪可以重放。因此,如果出于某种原因,我们离开了 Laravel Eloquent,也许我们使用了其他东西,我们可以创建一个新的操作 - 将实现绑定到我们的容器中,重放我们的事件,它应该都能正常工作。
在这个阶段,我们正在存储我们的事件并有办法改变我们的应用程序的状态 —— 但是我们做到了吗?我们需要告诉 Event Sourcing 库我们已经注册了这个 Projector/Handler 以便它知道在事件上触发它。通常我会为每个域创建一个 EventSourcingServiceProvider
,这样我就可以在一个地方注册所有的处理程序。我的看起来如下:
declare(strict_types=1); namespace Domains\Culture\Providers; use Domains\Culture\Handlers\CelebrationHandler; use Illuminate\Support\ServiceProvider; use Spatie\EventSourcing\Facades\Projectionist; final class EventSourcingServiceProvider extends ServiceProvider { public function register(): void { Projectionist::addProjector( projector: CelebrationHandler::class, ); } }
剩下的就是确保再次注册此服务提供者。我为每个域创建一个服务提供者来注册子服务提供者 —— 但这是另一个故事和教程。
在这个阶段,我们正在存储我们的事件,并有一种办法改变我们的应用程序的状态——但是我们做到了吗?我们需要告诉 Event Sourcing 库,我们已经注册了 Projector/Handler 以便它知道在事件上触发它。通常,我会为每个域创建一个EventSourcingServiceProvider
,以便可以在一个位置注册所有处理程序。如下:
declare(strict_types=1); namespace Domains\Culture\Providers; use Domains\Culture\Handlers\CelebrationHandler; use Illuminate\Support\ServiceProvider; use Spatie\EventSourcing\Facades\Projectionist; final class EventSourcingServiceProvider extends ServiceProvider { public function register(): void { Projectionist::addProjector( projector: CelebrationHandler::class, ); } }
剩下确保此服务提供者重新注册。我为每个域创建一个 Service Provider 来注册子服务提供者--但这是另一个故事和教程。
现在,当我们把它们放在一起时。我们可以要求我们的聚合创建一个庆祝活动,它将记录事件并将其保存在数据库中,并且作为副作用,我们的处理程序将被触发,随着新的变化改变应用程序的状态。
这似乎有点啰嗦,对吧?有没有更好的办法?可能,但在这一点上,我们知道何时更改了我们的应用程序状态。我们了解它们的制作原因。此外,由于我们的数据对象,我们知道谁进行了更改以及何时进行了更改。所以它可能不是最直接的方法,但它可以让我们更多地了解我们的应用程序。
你可以根據需要盡可能地進行此操作,也可以將腳趾浸入事件溯源中,這是最有意義的。希望本教學為你展示了一條清晰實用的路徑,讓你從今天開始使用事件溯源。
如果看完後你覺得意猶未盡, Spatie 很大方的提供了一張 7 折優惠券,可以用在他們 Laravel 課程裡的事件溯源部分,真是太棒了!造訪 課程網站 並使用優惠券碼 LARAVEL-NEWS-EVENT-SOURCING
。
你曾經使用過事件溯源嗎?你是怎麼處理的?在評論區告訴我們!
原文網址:https://laravel-news.com/event-sourcing-in-laravel
翻譯網址:https://learnku.com/laravel/t/ 71001
更多程式相關知識,請造訪:程式設計影片! !
以上是一文詳解Laravel中的事件溯源的詳細內容。更多資訊請關注PHP中文網其他相關文章!

Laravel在後端開發中的核心功能包括路由系統、EloquentORM、遷移功能、緩存系統和隊列系統。 1.路由系統簡化了URL映射,提高了代碼組織和維護性。 2.EloquentORM提供了面向對象的數據操作,提升了開發效率。 3.遷移功能通過版本控制管理數據庫結構,確保一致性。 4.緩存系統減少數據庫查詢,提升響應速度。 5.隊列系統有效處理大規模數據,避免阻塞用戶請求,提升整體性能。

Laravel在後端開發中表現強大,通過EloquentORM簡化數據庫操作,控制器和服務類處理業務邏輯,並提供隊列、事件等功能。 1)EloquentORM通過模型映射數據庫表,簡化查詢。 2)業務邏輯在控制器和服務類中處理,提高模塊化和可維護性。 3)其他功能如隊列系統幫助處理複雜需求。

選擇Laravel開發項目是因為其靈活性和強大功能適應不同規模和復雜度的需求。 Laravel提供路由系統、EloquentORM、Artisan命令行等功能,支持從簡單博客到復雜企業級系統的開發。

Laravel和Python在開發環境和生態系統上的對比如下:1.Laravel的開發環境簡單,僅需PHP和Composer,提供了豐富的擴展包如LaravelForge,但擴展包維護可能不及時。 2.Python的開發環境也簡單,僅需Python和pip,生態系統龐大,涵蓋多個領域,但版本和依賴管理可能複雜。

Laravel是如何在後端邏輯中發揮作用的?它通過路由系統、EloquentORM、認證與授權、事件與監聽器以及性能優化來簡化和增強後端開發。 1.路由系統允許定義URL結構和請求處理邏輯。 2.EloquentORM簡化數據庫交互。 3.認證與授權系統便於用戶管理。 4.事件與監聽器實現松耦合代碼結構。 5.性能優化通過緩存和隊列提高應用效率。

Laravel受歡迎的原因包括其簡化開發過程、提供愉快的開發環境和豐富的功能。 1)它吸收了RubyonRails的設計理念,結合PHP的靈活性。 2)提供瞭如EloquentORM、Blade模板引擎等工具,提高開發效率。 3)其MVC架構和依賴注入機制使代碼更加模塊化和可測試。 4)提供了強大的調試工具和性能優化方法,如緩存系統和最佳實踐。

Django和Laravel都是全棧框架,Django適合Python開發者和復雜業務邏輯,Laravel適合PHP開發者和優雅語法。 1.Django基於Python,遵循“電池齊全”哲學,適合快速開發和高並發。 2.Laravel基於PHP,強調開發者體驗,適合小型到中型項目。

PHP和Laravel不是直接可比的,因為Laravel是基於PHP的框架。 1.PHP適合小型項目或快速原型開發,因其簡單直接。 2.Laravel適合大型項目或高效開發,因其提供豐富功能和工具,但學習曲線較陡,性能可能不如純PHP。


熱AI工具

Undresser.AI Undress
人工智慧驅動的應用程序,用於創建逼真的裸體照片

AI Clothes Remover
用於從照片中去除衣服的線上人工智慧工具。

Undress AI Tool
免費脫衣圖片

Clothoff.io
AI脫衣器

AI Hentai Generator
免費產生 AI 無盡。

熱門文章

熱工具

SublimeText3漢化版
中文版,非常好用

Atom編輯器mac版下載
最受歡迎的的開源編輯器

VSCode Windows 64位元 下載
微軟推出的免費、功能強大的一款IDE編輯器

禪工作室 13.0.1
強大的PHP整合開發環境

DVWA
Damn Vulnerable Web App (DVWA) 是一個PHP/MySQL的Web應用程序,非常容易受到攻擊。它的主要目標是成為安全專業人員在合法環境中測試自己的技能和工具的輔助工具,幫助Web開發人員更好地理解保護網路應用程式的過程,並幫助教師/學生在課堂環境中教授/學習Web應用程式安全性。 DVWA的目標是透過簡單直接的介面練習一些最常見的Web漏洞,難度各不相同。請注意,該軟體中