README

Part of Barn.

The barnark command: clone an architecture template into your project under a name you give, make a folder to it, and check that the folder keeps to it. Built on Barnark.

Requirements

PHP 8.5+

Installation

composer global require rmb32/barnark-cli     # once, for every project
# or per project
composer require --dev rmb32/barnark-cli

Usage

barnark template:list                                    # the bound template, your own and the shipped ones
barnark template:clone "Library" Billing ./my-package    # clone Library into the project as Billing, and make its folder
barnark template:check                                   # check the bound folder against its template
barnark template:check "Library" ./other                 # check any folder against a shipped template
barnark template:copy Billing Invoicing                  # copy any template into a new one of your own
barnark template:delete Invoicing                        # delete one of your templates

barnark template:offers src/Context                      # what can be created in this folder?
barnark template:new Context Billing src/Context         # add a member to the template, and make its folders
barnark gui                                              # serve the browser UI and open it (needs rmb32/barnark-gui)

A project has one bound template, bound to one folder. template:clone makes them together: it copies a template, shipped or one of your own, under the name you give it, and makes a folder for each member it has. The copy is tied to nothing, so a later change to the template it came from never reaches it. A project that has its bound template already refuses another. The name can't be one the project already has, or a shipped template's name, ignoring case; --dry-run checks the template, the name and the target, and prints the folders it would make. The folder above the new one must exist.

Your own templates come from template:copy, which copies a shipped template, one of yours or the bound template, members included. Shipped templates are read-only. Deleting one of your own asks first, since only git brings it back (-n goes ahead without asking).

The project remembers which folder its template is bound to in .barnark/tracked-folders.json, and keeps each template, bound or not, in .barnark/templates/<name>/, at the project root (the nearest parent directory holding a .barnark/ folder, else where you run the command). A project that still has Barnark 5's barnark-workspace.json, or a tracked-folders.json binding several folders as Barnark 6 did, is refused, with the file's path, until you delete it or move it away.

Inside a barn

In a barn (a project whose root holds .barn/barn.json), every command works from any folder inside it. The records live in .barn/barnark/, and folder paths stay relative to the barn's root. The bound folder can be named the way the GUI shows it, from the root (barnark template:check /src), from any folder inside the barn.

cd src/Context
barnark template:new Context Billing .    # added to the template in .barn/barnark/templates/
barnark template:check                    # checks the barn's bound folder

template:check checks a real project's own contexts, features and aggregates where they actually are. A template's parts are the folders it names itself; its slots are what your own folders fill. Where the template leaves a folder no choice (every folder in Context/ is a Context), it is checked as filling that slot, and that works for an explicit template and directory too. A member added with template:new or the GUI is in the template, so if its folder is deleted by hand the check reports it as missing. Files are never checked: a template says only what folders there are.

The same template says what may be created in a folder, which is what template:offers reports and template:new acts on:

$ barnark template:offers src/Context/Billing/Domain
 ----------- ----------- -------------------------------------------------------------
  Slot        Key         Create it with
 ----------- ----------- -------------------------------------------------------------
  Aggregate   Aggregate   barnark template:new Aggregate <name> src/Context/Billing/Domain
 ----------- ----------- -------------------------------------------------------------

$ barnark template:new Aggregate Invoice src/Context/Billing/Domain

template:new adds a member you name to the template, as a new revision, then makes its folder with whatever fixed structure the slot carries — a Context arrives with its Domain, Application, Infrastructure and PublicApi. It never creates a file: what goes in a folder is yours to write, and nothing already on disk is overwritten. A member already in the template is refused.

A folder offers nothing when it holds only fixed parts (the root of a Domain Driven Design folder is all Kernel/Transport/Context), or when the template names nothing inside it, or when it sits outside the template.

Run barnark <command> --help for every option.

Command	Purpose
`template:list`	List the bound template, your own and the shipped ones
`template:clone`	Clone a template into the project under a name you give, and make its folder
`template:check`	Check the bound folder against its template, or a directory against a shipped template
`template:copy`	Copy a template into a new one of your own
`template:delete`	Delete one of your templates, with every revision
`template:offers`	List the slots a folder's template says can be filled inside it
`template:new`	Add a member the folder offers, under a name you give, to the template and the disk

rmb32 / barnark-cli

Package info

Security

Statistics

README

Requirements

Installation

Usage

Inside a barn

Related packages

More docs

License