Over the past few weeks, different people have asked me where a Command Bus goes in an Action-Domain-Responder system. While I\u2019m not a DDD expert, after brushing up on the subject a little, my answer is: \u201cIn the Domain.\u201d
\nFirst, let\u2019s recall the three components in ADR:
\n\u201cAction\u201d is the logic that connects the Domain and Responder. It uses the request input to interact with the Domain, and passes the Domain output to the Responder. (The Action is intentionally \u201cdumb\u201d: it should have no logic at all, aside from perhaps the most minimal of ternaries to allow for default input values. If the Action has a conditional, it is doing too much.)
\n\u201cDomain\u201d is the logic to manipulate the domain, session, application, and environment data, modifying state and persistence as needed. (The word \u201cDomain\u201d here is explicitly intended to remind you of \u201cdomain logic\u201d and \u201cdomain-driven design.\u201d)
\n\u201cResponder\u201d is the logic to build an HTTP response or response description. It deals with body content, templates and views, headers and cookies, status codes, and so on.
\nNext, let\u2019s see what Command Bus is. There\u2019s a lot written about it elsewhere \u2026
\nCommand Bus: An overview of implementation, advantages, and challenges
\n\u2026 so I\u2019ll try to sum up here:
\nA \u201cCommand\u201d is a typed or named set of inputs (essentially a data-transfer object) that gets sent to a \u201cCommand Bus.\u201d
\nThe \u201cCommand Bus\u201d then hands off the \u201cCommand\u201d to a \u201cCommand Handler\u201d specific to that \u201cCommand\u201d; the \u201cCommand Bus\u201d figures out which \u201cCommand Handler\u201d to use from the name or type of the \u201cCommand.\u201d
\nThe \u201cCommand Handler\u201d uses the \u201cCommand\u201d inputs to perform some sort of activity.
\nThis series of objects is part of an overarching architectural pattern called Command Query Responsibility Segregation (see here and here). Under CQRS, writes (Commands) are handled separately from reads (Queries). Handling a Command modifies data but does not return a result, while handling a Query returns a result but must not modify data.
\nThis means that a Command Bus does not actually return a result for inspection. You dump a Command into the Bus, and you\u2019re done; there\u2019s no checking for errors at that time. To conform to CQRS properly, you have to perform a separate Query in order to determine the result of the Command.
\nAt this point, just from having read the literature on the patterns and concepts, we can see that Command Bus and its related components are part of the domain layer, not part of the user interface layer. With that in mind, it seems like Command Bus is a candidate for the \u201cDomain\u201d portion of Action-Domain-Responder, to be used like this in an Action:
\nclass CreateItemAction\n{\n public function __construct(\n CommandBus $domain,\n CommandResponder $responder\n ) {\n $this->domain = $domain;\n $this->responder = $responder;\n }\n\n public function __invoke(Request $request)\n {\n $input = $request->getParsedBody();\n $command = new CreateItemCommand(\n $input['item_name'],\n $input['item_description']\n );\n $this->domain->handle($command);\n return $this->responder->createResponse();\n }\n}\nSo the Action gets constructed with a CommandBus element as an entry point into the Domain, and with a generic Responder to build the response. At invocation time, the user interface code sends along the current HTTP request; the Action pulls data out of it to create Command to send to the Command Bus, then tells the Responder to create an HTTP response. (Because a Command never returns anything, one Responder should suffice for all Commands in this setup.)
\nThis is straightforward as an minimal case, but I think it avoids at least two substantial issues.
\nWhere does input validation go? (Input validation, or form validation, is separate from domain model validation.)
\nWhere does error handling go? (While a Command might not return anything, the various elements related to CQRS might very well throw exceptions or raise errors.)
\nIn what we think of as server-side MVC, those two concerns might well be placed in the Controller somewhere. Translating a Controller method directly to an Action, that might look something like this:
\n public function __invoke(Request $request)\n {\n // get the input and validate it\n $input = $request->getParsedBody();\n if (! $this->validate($input)) {\n // create an \"invalid input\" response\n return $this->responder->invalid($input);\n }\n\n // create the command\n $command = new CreateItemCommand(\n $input['item_name'],\n $input['item_description']\n );\n\n // try the command\n try {\n $this->domain->handle($command);\n // succcess!\n return $this->responder->success();\n } catch (Exception $e) {\n // there was some sort of subsequent failure\n return $this->responder->failure($e);\n }\n }\nOn consideration, that seems like a lot of extraneous activity in the user interface layer. In ADR, the Action is intentionally supposed to be dumb. It should not be doing anything even remotely interesting, and certainly should not be dealing with any conditional logic.
\nAs such, I say that Command-related activity should be taken out of the Action entirely, and relegated to something like an Application Service or some other Domain entry point. That Service is what should perform the Command-related activity.
\nFurther, while a Command may not return a result, a Service certainly can. This means that the Action can call the Domain and get back a Domain Payload as a result, which can then be passed to the Responder for presentation.
\nUnder that way of thinking, we get something more like this:
\nclass CreateItemAction\n{\n public function __construct(\n ItemService $domain,\n CreateItemResponder $responder\n ) {\n $this->domain = $domain;\n $this->responder = $responder;\n }\n\n public function __invoke(Request $request)\n {\n $input = $request->getParsedBody();\n $payload = $this->domain->create($input);\n return $this->responder->createResponse($payload);\n }\n}\n\nclass ItemService\n{\n public function create(array $input)\n {\n if (! $this->validate($input)) {\n // create an \"invalid input\" response\n return new InvalidInputPayload($input);\n }\n\n // create the command\n $command = new CreateItemCommand(\n $input['item_name'],\n $input['item_description']\n );\n\n // try the command\n try {\n $this->domain->handle($command);\n return new CommandAcceptedPayload();\n } catch (Exception $e) {\n return new CommandRejectedPayload($e);\n }\n }\n}\nNow the Domain is fully separated from the user interface. It can be used with both HTTP and command-line interfaces, and tested separately from them. Per the ADR pattern, the Responder becomes responsible for examining the Payload to see what kind of presentation to deliver to the client. Different Payloads result in different responses being built. Finally, the Action becomes entirely uninteresting; all of the business logic has been pushed down into the Domain, where it belongs.
\nSo, to sum up: Command Bus is a domain layer pattern, and should be used in the Domain, not in the Action. A Command cannot return a result, but a Service can, so the entry point into the Domain is probably better as a Service that returns a Payload. This keeps the HTTP and CLI user interface logic well separated from business logic, and independently testable and reusable.
\nRead the Reddit discussion about this post here.
\n" }