PHP Training – From Monolith to Modular Architecture
Level
AdvancedDuration
16h / 2 daysDate
Individually arrangedPrice
Individually arrangedPHP Training – From Monolith to Modular Architecture
This workshop teaches system design through the evolution of existing code, rather than building an application from scratch. Participants work with a functioning e-commerce monolith and redesign it step by step: identifying hidden coupling, discovering bounded contexts using EventStorming, and then physically separating the code into modules with enforced boundaries. Every change is incremental and verifiable — deptrac enforces architectural boundaries, tests protect against regressions, and GitHub Actions automate quality checks. The workshop concludes with a modular monolith featuring clearly defined contexts, domain events, and a CI pipeline that prevents the codebase from becoming tightly coupled again.
Graduates of the PHP Fundamentals + Advanced workshop who are ready to move to an architectural level
PHP developers with commercial experience who can independently build a REST API with tests
Developers working with monoliths where “a change in one place breaks three others”participants who want to learn how to build web applications using PHP or organize and enhance their existing skills
Teams that want to introduce modularity into existing applications without rewriting them from scratch
Requirements
- PHP 8.3+: object-oriented programming, interfaces, dependency injection
- PHPUnit testing: unit and integration tests
- Knowledge of SRP and DIP — ability to explain them using an example from your own code
- Experience with REST APIs using Symfony Components or a full framework (Symfony/Laravel)
- Docker and Composer
What will you learn?
- How to analyze dependencies in existing code using deptrac
- EventStorming as a method for discovering the domain and identifying bounded contexts
- Domain-Driven Design (strategic + tactical) — Ubiquitous Language, aggregates, and domain events
- How to refactor a monolith into a modular monolith with enforced boundaries between modules
- How to enable communication between modules through domain events using Symfony EventDispatcher
- How to enforce architectural boundaries with deptrac as a CI guard
- How to document architectural decisions using ADR (Architecture Decision Records)
- How to configure a CI pipeline with GitHub Actions, including deptrac, PHPUnit, and PHPStan
Training Program
Day 1
Stage 1: Anatomy of the Problem
- Reviewing the existing monolith — what works, what causes problems, and where hidden dependencies exist
- Reading logs (structured logging) — understanding data flow
- deptrac — generating a dependency map between classes
- Identifying hidden coupling — “Why does changing the catalog break orders?”
Outcome:
Participants can see the monolith’s dependency map and understand where the problems lie
Stage 2: DDD — Strategic Design
- EventStorming — collaborative domain discovery and identification of business events, commands, and aggregates
- Ubiquitous Language — why “product” can mean something different in the catalog, cart, and warehouse
- Bounded Contexts — defining boundaries (Catalog, Cart, Order) based on the results of EventStorming
Outcome:
The monolith is conceptually divided into contexts; participants understand why these boundaries exist, not just where to draw them.
Day 2
Stage 3: DDD Tactical + Modular Monolith
Theory and practice are combined in iterative cycles: identify → extract → verify.
Cycle 1 — First Module: Catalog
- Directory structure —
src/Catalog/as a standalone unit - Public module API — interfaces as contracts; implementation hidden
- Moving catalog-related code into the module
- deptrac — adding the first rule and verifying the boundary
Cycle 2 — Second Module: Order + Communication
- Aggregates — modeling business rules that enforce their own consistency
- Domain events —
OrderPlacedas a contract between contexts - Communication between modules — Symfony EventDispatcher
- Internal vs. Published events — not every event needs to be public
Cycle 3 — Verification and Enforcement
- deptrac as a CI guard — full configuration
- Module testing — integration tests for modules in isolation
- Cart as an exercise — participants extract the third module independently
Outcome:
The code is physically separated into modules with enforced boundaries and communication through events.
Stage 4: Architecture in Everyday Development
- ADR (Architecture Decision Records) — documenting architectural decisions
- Fitness functions — GitHub Actions with deptrac, PHPUnit, and PHPStan as an automated quality gate
- When not to use DDD/modularization — over-engineering is also an anti-pattern
- Retrospective — what changed in the monolith and what we learned
Outcome:
Participants leave with a decision-making framework and a CI pipeline, not just technical knowledge.