Демистифицированные командные автобусы: взгляд на тактический пакет

 final class CreateDeck { /** * @var string */ private $id ; /** * @param string $id */ public function __construct ( $id ) { $this - > id = $id ; } /** * @return DeckId */ public function getId ( ) { return DeckId : : fromString ( $this - > id ) ; } } 

В этом примере и в оставшейся части этой статьи мы будем использовать команду в качестве сообщения. Он фиксирует намерения пользователя и содержит данные, необходимые для выполнения задачи. Он явно описывает поведение, которое может выполнять система. Следовательно, Команды имеют обязательное имя, например: CreateDeck , ShuffleDeck и DrawCard .

Команды обычно называются DTO (объектами передачи данных), так как они используются для хранения данных, переносимых из одного места в другое. Команды поэтому неизменны. После создания данные не должны меняться. Вы заметите, что наша команда примера CreateDeck содержит установщиков или любого другого способа изменить внутреннее состояние. Это гарантирует, что он не может измениться во время передачи в обработчик.

Обработчики команд

Обработчики интерпретируют намерение определенной Команды и выполняют ожидаемое поведение. Они имеют отношение 1: 1 к командам — ​​это означает, что для каждой команды всегда есть только один обработчик.

 final class CreateDeckHandler { /** * @var DeckRepository */ private $decks ; /** * @param DeckRepository $decks */ public function __construct ( DeckRepository $decks ) { $this - > decks = $decks ; } /** * @param CreateDeck $command */ public function handle ( CreateDeck $command ) { $id = $command - > getId ( ) ; $deck = Deck : : standard ( $id ) ; $this - > decks - > add ( $deck ) ; } } 

В нашем примере выше создается новая колода. Также важно отметить, что не происходит. Это не заполняет представление; вернуть код ответа HTTP или записать на консоль. Команды могут выполняться из любого места, поэтому обработчики остаются независимыми от вызывающей среды. Это чрезвычайно полезно при построении границ между вашим приложением и внешним миром.

Командная шина

И, наконец, сама командная шина. Как кратко объяснено выше, ответственность Командной шины состоит в том, чтобы передать Команду своему Обработчику. Давайте посмотрим на пример.

Представьте, что нам нужно предоставить конечную точку RESTful API, чтобы разрешить создание новых колод:

 use Illuminate \ Http \ Request ; final class DeckApiController { /** * @var CommandBus */ private $bus ; /** * @var CommandBus $bus */ public function __construct ( CommandBus $bus ) { $this - > bus = $bus ; } /** * @var Request $request */ public function create ( Request $request ) { $deckId = $request - > input ( 'id' ) ; $this - > bus - > execute ( new CreateDeck ( $deckId ) ) ; return Response : : make ( "" , 202 ) ; } } 

Теперь представьте, что вам нужно создавать новые колоды с консоли. Мы можем справиться с этим требованием, снова передав эту же команду через шину:

 class CreateDeckConsole extends Console { /** * @var string */ protected $signature = 'deck' ; /** * @var string */ protected $description = 'Create a new Deck' ; /** * @var CommandBus */ private $bus ; /** * @var CommandBus $bus */ public function __construct ( CommandBus $bus ) { $this - > bus = $bus ; } public function handle ( ) { $deckId = $this - > argument ( 'id' ) ; $this - > bus - > execute ( new CreateDeck ( $deckId ) ) ; $this - > comment ( "Created: " . $deckId ) ; } } 

Примеры не касаются деталей реализации создания колод. Наши Командные и Консольные Команды используют Командную Шину для передачи инструкций Приложению, что позволяет им сосредоточиться на том, как следует отвечать на их запросы. Это также позволяет нам удалить то, что потенциально могло быть много дублированной логики.

Тестирование нашего контроллера и консольной команды теперь является тривиальной задачей. Все, что нам нужно сделать, это утверждать, что команда, переданная в шину, была правильно сформирована на основе запроса.

пример

Пример приложения рассматривает колоду карт для домена. Приложение имеет ряд команд: CreateDeck , ShuffleDeck и DrawCard .

До этого момента CreateDeck предоставлял контекст только при изучении концепций. Затем мы установим Tactician в качестве нашей командной шины и выполним нашу команду.

Конфигурирование тактика

После того, как вы установили Tactician , вам нужно будет настроить его где-нибудь в начальной загрузке вашего приложения.

В нашем примере мы поместили это в скрипт начальной загрузки, однако вы можете добавить это к чему-то вроде контейнера внедрения зависимости.

 public function __construct ( CommandNameExtractor $commandNameExtractor , HandlerLocator $handlerLocator , MethodNameInflector $methodNameInflector ) 

 use League \ Tactician \ CommandBus ; use League \ Tactician \ Handler \ Locator \ InMemoryLocator ; use League \ Tactician \ Handler \ CommandHandlerMiddleware ; use League \ Tactician \ Handler \ MethodNameInflector \ HandleInflector ; use League \ Tactician \ Handler \ CommandNameExtractor \ ClassNameExtractor ; $handlerMiddleware = new CommandHandlerMiddleware ( new ClassNameExtractor , new InMemoryLocator ( [ ] ) , new HandleInflector ) ; $bus = new CommandBus ( [ $handlerMiddleware ] ) ; 

 $locator = new InMemoryLocator ( [ ] ) ; $handlerMiddleware = new CommandHandlerMiddleware ( new ClassNameExtractor , $locator , new HandleInflector ) ; 

 <?php require 'bootstrap.php' ; $deckId = DeckId : : generate ( ) ; $newDeckCommand = new CreateDeck ( ( string ) $deckId ) ; 

 $decks = new InMemoryDeckRepository ; $locator - > addHandler ( new CreateDeckHandler ( $decks ) , CreateDeck : : class ) ; 

 $bus - > handle ( $newDeckCommand ) ; var_dump ( $decks - > findById ( $deckId ) ) ;