Download the PHP package lezhnev74/ddd-generator without Composer
On this page you can find all versions of the php package lezhnev74/ddd-generator. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
Download lezhnev74/ddd-generator
More information about lezhnev74/ddd-generator
Files in lezhnev74/ddd-generator
Package ddd-generator
Short Description DDD Generator for 3-layered applications
License MIT
Informations about the package ddd-generator
DDD Classes Generator for 3-layered Application
When you develop clean and decoupled app you have to deal with many interfaces and objects. Where you had one object in RAPID development flow, you have plenty of objects in DDD flow. To speed things up I use this tool to generate primitives related to ServiceBus pattern, CQRS pattern and Clean Architecture. If you interested - I blogged about ideas behind this generator.
Note: I use PSR-4 so any folder inheritance leads to namespace inheritance (and vice versa). And also type of slashes is irrelevant - \ and / will do the same.
Note: This tool is designed to be extensible. So while it contains packs to generate widely used primitives like commands, there can be easily added packs to generate http controllers (+tests) and views and anything else.
Note: No Windows support in mind.
In a nutshell
This is a handy tool to generate empty class files + test files from templates and put them in predictable places.
- set the config
- run command with given config
What it can generate
- anything you want
- CommandBus: command and handler classes
- QueryBus: request, response and handler
- VO and Entity
- Event
- anything else
Each class is complimented with empty test so I can keep TDD-ing.
Installation
Via composer:
Usage
Command arguments:
<layer_name>
- 3 types available: "app", "domain" or "infrastructure"<primitive_type>
- "command" or anything you set up in the config file<primitive_namespace>
- psr-4 inspired path to the file, which also serves as a namespace. F.e. "Account/Commands/SignUp"
More usage examples:
Config
You can set folders where new files will go to. You can configure each primitive - set its alias and set stubs to generate new files from.
Templates
Each primitive can have multiple templates (stubs). F.e. command has command and handler templates, query has request, response and handler templates. Event will only have event template and test. So configuration explicitly declares which files to generate and in which folder.
Template support few placeholders which reflects user input:
/*<BASE_SRC_NAMESPACE>*/
- looks like\App
(each layer may have different one)/*<BASE_TEST_NAMESPACE>*/
- looks like\Domain\Tests
(each layer may have different one)/*<LAYER>*/
- app or domain or infrastructure/*<PRIMITIVE>*/
- the name of the primitive f.e.event
orcommand
/*<PSR4_NAMESPACE>*/
- looks likeAccount\Command\SignUp
, seeargument /*<PSR4_NAMESPACE_BASE>*/
- looks likeAccount\Command
(without final part)/*<PSR4_NAMESPACE_LAST>*/
f.e.SignedUp
(just final part)/*<FILENAME>*/
f.e.SignedUpCommand
(the final filename for this stub)
This how stub for a test file can look like inside:
How it works
Take for example the config file shown above and let's explain this command:
bin/dddtool generate domain command Account\Commands\SignUp
The script will do this:
- first, command will detect the layer for which you want to generate new files. In our case it is "domain"
- then layer's config is detected
- then command analyze the primitive name, in our case it is "command"
- then config for this primitive is being detected
- then for each stub in the config a new file is prepared. For example, test stub with name
/*<PSR4_NAMESPACE_LAST>*/CommandTest
will actually be created in file__DIR__ . "/tmp/tests/Account/Commands/SignUp/SignUpCommandTest.php"
. - user sees the list of files which are supposed to be generated
- after confirmation real files are generated and put to file system.
TODO
- I am thinking about adding conditions to stub configuration, so user can be asked if he wants to skip some optional stubs for a given primitive.
- I wonder if I can simplify the design of this tool in any way?