如何在CQRS体系结构中创建读写分离的repos

Question

我有这个空间和存储库

<?php

namespace App\Domain\Model\User;

interface UserRepositoryInterface
{
    public function findNextId(string $id = null): string;

    public function findOneById(string $id): ?User;

    public function findOneByEmail(string $email): ?User;

    public function save(User $user): void;

    public function remove(User $user): void;
}


final class DoctrineUserRepository implements UserRepositoryInterface {...}

现在，根据CQRS，我必须将我的回购分成2次回购。一个是读的，一个是写的，对吧？所以把我的界面分割成两个接口。

    <?php

namespace App\Domain\Model\User;

interface UserRepositoryReadInterface
{
    public function findNextId(string $id = null): string;

    public function findOneById(string $id): ?User;

    public function findOneByEmail(string $email): ?User;
}

And write:
<?php

namespace App\Domain\Model\User;

interface UserRepositoryWriteInterface
{
    public function save(User $user): void;

    public function remove(User $user): void;
}

并且应该创建DoctrineUserWriteRepository.php和DoctrineUserReadRepository.php。对吗？我真的迷失在这里面了。红吨的发音，但解释得绝对不清楚。

Answer 1

对，所以您在这里所做的是使用存储库模式来拆分代码以实现CQRS体系结构。

我不知道为什么要使用存储库模式这样做，因为在大多数情况下，使用CQRS的想法是与DDD和其他体系结构等一起使用的(我不打算说应该这样做，而是根据我的经验和与不同的团队一起工作……)。

另一方面，如果您只是尝试使用存储库模式来获得更好的和有组织的代码，那么就继续做，但是在另一方面，您应该意识到，大多数情况下，人们不喜欢像这些案例那样的工程项目，而这些人不仅仅是初级人员。

无论如何，在本例中，我宁愿首先使用Services，下面是一个示例：

让我们从安装Ecotone开始，我在许多项目(当然是大项目)中亲自使用并看到了它。composer require ecotone/laravel

然后您可以构建您的服务：

// I'll call this UserService since you've pointed to User in your repository pattern.

class UserService
{
    #[CommandHandler]
    public function save(SaveUserCommand $command) : void
    {
        // get user and save new info, create new one Or etc.
    }

    #[QueryHandler]
    public function findOneByEmail(GetUserEmaillAddressQuery $query)
    {
        $userFoundOut= User::where(... or find or etc. // use the query
        // to get user by email address or id or etc.;

        return $userFoundOut;
    }
}

在上面的代码中，我们用query and command创建了query and command，您可能会想到为什么它们都在一个类中，我应该说，我与许多人一起工作，在许多项目中，我看到人们使用一个类来完成这个任务，而在其他一些场景中，他们使用两个类来分离query和command。

我宁愿将它们分开，做一些类似于UserQueryServices Or UserCommandServices的事情，但在其他方面，您可能会与类似于铅架构的人一起工作，在这种情况下，他们将决定在构建上下文等基础上做什么(这一点根本没有什么问题，也不认为这个类想法是个坏主意。)

在控制器中，查询示例请参见下面的内容：

class UserController
{
    public function __construct(private QueryBus $queryBus) {}


    public function getUserEmailAddress(Request $request)
    {
        $userId = $request->get('user_id');

        $user = $this->queryBus->send(new GetUserEmaillAddressQuery($userId));

        return new response($user->email);
    }
}

class GetUserEmaillAddressQuery 
{
    public function __construct(private string $user_Id) {}

    public function getUserId(): string
    {
        return $this->user_Id;
    }
}

当然也是为了指挥：

class UserController
{
    public function __construct(private CommandBus $commandBus) {}
    
    public function saveUser(Request $request)
    {
        $userId = $request->get('user_id');
        $name = $request->get('user_name');
        $email = $request->get('user_email');
        $something_cool= $request->get('something_cool');
        
        $this->commandBus->send(new SaveUserCommand($userId, $name $email ,$something_cool));
        
        return new response('done');
    }
}

class SaveUserCommand
{
    public function __construct(private string $user_id, private string $name,
private string $email, private string $something_cool) {}

    public function getUserId(): string
    {
        return $this->user_id;
    }

    public function getEmail(): string
    {
        return $this->email;
    }

    public function getSomethingCool(): string
    {
        return $this->something_cool;
    }


    public function getName(): string
    {
        return $this->name;
    }
}