· 1 min read · updated
When DDD Fits a Project, and When It Does Not
DDD is useful for complex software projects where understanding the domain is crucial, but it may not be the best choice for smaller or simpler projects. The decision to use DDD should be based on careful evaluation of the project's requirements and constraints. For new projects, it depends on the project's needs and for legacy systems, introducing DDD requires careful planning to avoid disrupting the system's stability.
$ related posts
18 min readNEW
The Application Layer, the Transaction, and a Working API
Application layer in Symfony 8: use cases on a Messenger command bus, the transaction boundary in config, optimistic locking and RFC 9457 errors. Part 2.
DDD, CQRS and Hexagonal Architecture in Symfony 8 · part 2#ddd#hexagonal-architecture#symfony#php#cqrs#messenger#software-architecture15 min readNEW
The Domain Model, and the Only Rule That Matters
DDD domain model in PHP 8.5 and Symfony 8: keep the container out of the domain, and choose Doctrine ORM or DBAL with the costs on the table. Series part 1.
DDD, CQRS and Hexagonal Architecture in Symfony 8 · part 1#ddd#hexagonal-architecture#symfony#php#doctrine#software-architecture7 min read
Alternatives to Domain-Driven Design, and When to Use Them
DDD is not a default. The real alternatives, transaction script, active record, table module and tactical-only DDD, and how to tell which you need.