Domain rules object/class in laravel - php

Question

I am trying to structure a large laravel application.
Trying to figure out:
1) Where does business rules / domain rules objects go?
2) How does business rules objects looks like?
By business rules I mean rules like. Given an invoice has possible states [new, approved, completed]. Only invoices in the "approved" state can be emailed to a customer. This is a simplified example.
Since there are a lot of these rules and these rules change often (once or twice a year), I would like to have them in dedicated classes.
This blog post https://stitcher.io/blog/laravel-beyond-crud-01-domain-oriented-laravel provides an application structure similar to my desired application structure. See below.
app/Domain/Invoices/
├── Actions
├── QueryBuilders
├── Collections
├── DataTransferObjects
├── Events
├── Exceptions
├── Listeners
├── Models
├── Rules
└── States
I'm somewhat familiar with domain driven design "theory". I am looking for code examples, preferably in Laravel or PHP (other languages are also ok). If anyone can point me to a github/gitlab project with code examples that would be great as well.

Answer 1

First I'll provide an example, which will be explained below.
<?php
namespace App;
use RuntimeException;
class Invoice
{
private const STATUS_NEW = 'new';
private const STATUS_APPROVED = 'approved';
private const STATUS_COMPLETED = 'completed';
/** #var string */
private $status;
private function __construct(string $status)
{
$this->status = $status;
}
public function create(): self
{
return new self(self::STATUS_NEW);
}
public function approve(): void
{
if ($this->status !== self::STATUS_NEW) {
throw new RuntimeException('Unable to approve invoice, as it is not new');
}
$this->status = self::STATUS_APPROVED;
}
public function complete(): void
{
if ($this->status !== self::STATUS_APPROVED) {
throw new RuntimeException('Unable to complete invoice, as it is not new');
}
$this->status = self::STATUS_COMPLETED;
}
public function canBeSentToCustomer(): bool
{
return $this->status === self::STATUS_COMPLETED;
}
}
So there's a few ideas behind the code above:
The class and method names reflect the domain language. Example: somebody in sales will talk about approving an invoice, which translates to $invoice->approve()
The class is responsible for maintaining a valid state itself. Example: an invoice can't be completed if it's not approved yet
The code does not care about frameworks, databases, web requests, emails or html. All it should do is implement behavior without worrying about where the input comes from or output goes to.