Persist PHP Datatypes value objects with Doctrine DBAL - Laravel auto-wired, zero configuration

php-datatypes-laravel-doctrine

This package lets a hradigital/php-datatypes object be the declared type of a Doctrine Entity attribute. Doctrine persists only the types it ships with, so an EmailAddress, a Money or an Address would otherwise have to be declared as a primitive and converted by hand on every read and write. It ships one Doctrine DBAL Type per Datatypes object, plus a Laravel Service Provider that registers them all, so the Entity holds the Value Object while the database still holds a plain, indexable, human-readable value.

• Doctrine DBAL Types - one per Datatypes object: StrType, EmailAddressType, UrlType, SlugType, DatetimeType, CurrencyType, MoneyType, AddressType and the rest.
• Native PHP Types - NativeDateTimeType, NativeDateTimeImmutableType, NativeDateIntervalType and NativeDateTimeZoneType, so an Entity holding a plain \DateTime maps under the same naming convention.
• Laravel Service Provider - auto-discovered, registering every Type before any EntityManager resolves a mapping. Nothing to publish, nothing to configure.
• One naming rule - a Doctrine type name is always the Type class' own short name.
• Validation on the way in - a Value Object's validation failure surfaces as a DBAL ConversionException, so an invalid value is rejected rather than corrupting the column.
• Framework-optional - the Types are plain DBAL Types with no framework dependency; the Service Provider is a convenience.

What this package is not

• Not a fork or a replacement for hradigital/php-datatypes. It depends on it and adds persistence, nothing more. The Value Objects' behaviour, validation and API are entirely theirs.
• Not an ORM, and not a set of Entities. It contributes column types. Your Entities, mappings and repositories stay yours.
• Not Laravel-only. See Using it outside Laravel.

Full-stack platform built for a construction and civil engineering company in Portugal — bringing together their public site, project portfolio, recruitment, news, and client testimonials in one cohesive Laravel application.

Architected around bounded contexts covering the company's real-world domains (company info, projects, recruitment, news, testimonials, notifications, and more), following Event-Driven Domain-Driven Design and Clean Architecture, with a dedicated queue-based pipeline decoupling side effects from core domain logic.

Fully tested across the full pyramid — Unit, Integration, Functional, Feature, System, and E2E.

Laravel wrapper for PHP-Exception's Library, wiring Laravel's error handling and providing a Rendered for these Exceptions

php-exceptions-laravel

Laravel wiring and JSON / web renderers for the hradigital/php-exceptions domain exception tree.

The base library ships platform-agnostic exceptions - AbstractBaseException and the Client/ and Server/ trees, aligned with HTTP 4xx/5xx semantics - and knows nothing about a transport, leaving every application to decide again how a thrown domain exception becomes a response.

This package decides it once. API requests get a uniform JSON body; web requests throwing a 422 land back on the originating form with errors and old input; every other package exception is answered on the web with the HTTP status it declares. An exception that does not extend AbstractBaseException falls through to Laravel's own handler, untouched.

• ExceptionRenderer - the JSON strategy dispatcher, resolving an exception to the first strategy that supports it, with an always-matching fallback.
• WebRenderer - the web strategy dispatcher, resolving an exception to the first strategy that supports it, with an always-matching fallback.
• ExceptionsServiceProvider - auto-discovered, binding both dispatchers as singletons and registering two renderable() hooks on Laravel's exception handler.
• API detection - one shared rule across both hooks: the Accept header, a JSON body, an api/* path, or an api.* route name.
• Bundled strategies - DefaultRenderer and InputFailureRenderer for JSON, InputFailureWebRenderer, UnprocessableEntityWebRenderer and DefaultWebRenderer for the web.
• Custom strategies - resolve the singleton and prepend your own; the last registration wins.

Semantic, HTTP-aligned domain exceptions for PHP 8.1+ DDD applications - framework-agnostic, zero runtime dependencies

php-exceptions

A curated set of reusable, semantic domain exceptions for Domain-Driven Design PHP applications. Their names mirror the HTTP 4XX/5XX families because that vocabulary is widely understood, but they are raised in the domain layer, outside any transport, and translated at the boundary into an HTTP response, RPC error, CLI exit or queue dead-letter. Throwing the right exception is part of your domain language, where a generic InvalidArgumentException leaks plumbing into it. Framework-agnostic, with zero runtime dependencies beyond the PHP standard library, on any PHP 8.1+ project.

• Client exceptions - caller-fault types aligned to the 4XX family, from BadRequestException through UnavailableForLegalReasonsException, each with a default message and status code.
• Server exceptions - system-fault types aligned to the 5XX family, from InternalServerErrorException through LoopDetectedException.
• AbstractBaseException - the common base, extending PHP's native \DomainException, so a single catch captures everything in this package.
• Request\RequestFailureException - structured per-field validation failures, for one rejected payload carrying many reasons.
• Extension by intent - every type is meant to be extended by your own named exception, so callers can still catch the broader intent.

Requirements

Installation

composer require hradigital/php-exceptions

Usage

Every exception in this package extends AbstractBaseException, which itself extends PHP's native \DomainException. Each subclass ships with a sensible default message and an HTTP-aligned status code ($code).

use HraDigital\Components\Exceptions\Client\NotFoundException;

throw new NotFoundException('User #42 does not exist.');

State-aware client-side form manager for static HTML forms. Tracks per-field state (new, unchanged, changed, invalid, empty) and toggles toolbar actions accordingly

@hradigital/smartforms

State-aware client-side form manager for static HTML forms. It layers reactive behaviour onto the HTML a server-rendered app already produces, driven entirely by attributes - mark a <form> with the smartform class and it takes over. Fields, toolbar buttons and HTTP actions then follow the form's state, with no React or Vue and no rewrite of the markup the server already sends.

• Per-field state - tracks new, unchanged, changed, invalid and empty, applying a matching CSS class for styling.
• Two layouts - a list of records (smartformlist) or a single record (smartformrecord).
• Toolbar wiring - enables and disables create, update, delete and cancel buttons from the form's overall state.
• HTTP Tasks - binds a toolbar action to a verb and endpoint, declared in markup.
• formStateChange events - a CustomEvent per state transition, for anything the library does not cover.
• No framework, no build step - ESM, CJS and a UMD build loadable straight from a <script> tag.

Installation

npm install @hradigital/smartforms
# or
yarn add @hradigital/smartforms
# or
pnpm add @hradigital/smartforms

Or load the UMD build directly in the browser:

<script src="https://unpkg.com/@hradigital/smartforms/dist/smartforms.umd.js"></script>
<script>
    SmartForms.autoInit();
</script>

hradigital.com is my personal engineering portfolio, built as a working extension of my CV and LinkedIn profile rather than a static page. It's a six-locale (EN/PT/FR/ES/DE/NL) Laravel application, architected with the same Event-Driven Domain-Driven Design and Clean Architecture principles I apply in production fintech systems — clear separation between Application, Domain, Framework, and Infrastructure layers, following SOLID.

The site actively pulls and displays live, dynamic content rather than hard coding it, all wired through REST API integrations. It's fully tested across the full pyramid — Unit, Integration, Feature, Functional, System, and E2E — and reflects the same engineering discipline I bring to client work: bounded contexts, domain events, and infrastructure that stays out of the domain's way.

GitHub Action to calculate the next release version based conventional commits

Semver Conventional Commits - Github Action

This GitHub Action automatically determinate the next release version to use based on all the Conventional Commits since the latest tag.

• Example Workflow
• Inputs
• Outputs

Example workflow

name: Deploy

on:
  push:
    tags:
      - v[0-9]+.[0-9]+.[0-9]+

jobs:
  deploy:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout Code
        uses: actions/checkout@v2

      - name: Get Next Version
        id: semver
        uses: ietf-tools/semver-action@v1
        with:
          token: ${{ github.token }}
          branch: main

      - name: Create Release
        uses: ncipollo/release-action@v1
        with:
          allowUpdates: true
          draft: false
          name: ${{ steps.semver.outputs.next }}
          body: Changelog Contents
          token: ${{ github.token }}

Inputs

Outputs

:warning: Important :warning:

You must already have an existing tag in your repository. The job will exit with an error if it can't find the latest tag to compare against!

Help maintain current Fintech solution, and help transition parts of the system to a microservice architecture.

• Based on LAMP (Laravel & Symfony).
• Distinct separation between Application & Domain layers (Framework & Infrastructure as well).
• Domain Driven Design and Test Driven Development.
• Applying best industry standards (Design Patterns/Design Principles).

Developing a trading platform project for financial asset transactions.

Event-driven microservice project, as part of a bigger Fintech SaaS solution, involving blockchain tokens and e-wallet management. Based on LAMP (Laravel).

• Developing using Micro-service and Event-driven Architecture.
• Distinct separation between Application and Domain layers.
• Domain Driven Design and Test Driven Development.
• Applying best industry standards (Design Patterns/Design Principles).

DDD building blocks for PHP: one tested Trait per attribute, plus immutable Str/int/float, Slug, Url, EmailAddress, Money and datetime Value Objects. Framework-free, no 3rd party dependency.

PHP Datatypes

PHP Datatypes builds your Value Objects, Entities and Aggregates from predefined, tested Traits - one per attribute - leaving the class definition free for the business logic that belongs to it.

Getters return Value Objects rather than primitives wherever possible, so a value carries its own validation and normalization instead of every caller remembering it. There is no 3rd party dependency beyond PHP itself, so these values work without a framework, an HTTP request or a template engine.

• AbstractValueObject - the base a Value Object, Entity or Aggregate extends, giving it construction from an array, full serialization and toArray() out of the box.
• Entity Traits - one Trait per attribute (HasPositiveIntegerIDTrait, HasActiveTrait, HasNameTrait, ...), each carrying the type hints and normalization for that attribute.
• Scalar datatypes - immutable Str, integer and float wrappers, with a fluent API that returns a new instance on every operation rather than mutating the value in place.
• Web datatypes - Slug, Url and EmailAddress, each validating and normalising itself.
• Datetime datatypes - date and time values, without pulling in a datetime library.
• Exception vocabulary - a typed exception per datatype under Exceptions\Datatypes\*, so a rejected value says what it rejected and why.

Scope

This package holds datatypes: values that validate and normalise themselves, and that any PHP application can use without a framework, an HTTP request or a template engine. The "No 3rd party dependency" rule is a scope rule as much as a dependency rule.

Behaviour that renders, parses documents, or exists to serve a web page is not a datatype, and lives in hradigital/php-markup instead. php-markup depends on this package - never the other way round.

The project is based on LAMP in the back-end, on top of Laravel's framework. The project is broken into different packages, that are use in more than one project/distribution, being LRTT's one of them. On the front-end, we use HTML5 with Bootstrap and React.

My first assignment in the project, was to adapt functionality for more user roles, adapt the system for multi-role user registration and authentication, create a new role's dedicated area, and develop API functionality for the front-end.

On the front-end, apart from creating a new dedicated user role's area, was to develop a React application that managed Fellowship's information for a registered volunteer teacher.

While developing for this project, on of my jobs was to migrate code to PHP7's syntax, and document new and existing code using PHPDocs.

Layout and database restructuring. Table-based refacing and re-development of the company's websites, with new functionalities, adopting the same corporative image, and shared resources.