Copy-Based Framework
Phexium uses a copy-based distribution model rather than a traditional package dependency approach. The framework code lives directly in your project's src/ directory, not hidden in vendor/.
Key Benefits
| Benefit | Description |
|---|---|
| No framework lock-in | You own 100% of the framework code |
| Full transparency | All framework code is visible and modifiable |
| Local customization | Modify framework sources without forking |
| Selective updates | Update framework when needed, not forced by dependencies |
| Git-native workflow | Leverage Git for tracking changes and updates |
How It Differs
When you clone Phexium, you receive the complete framework source code as part of your project:
| Aspect | Traditional Frameworks | Phexium |
|---|---|---|
| Location | vendor/ (read-only) | src/ (your code) |
| Ownership | External dependency | Part of your project |
| Modifications | Fork required | Direct editing |
| Updates | Composer forces version | You choose when and what |
| Visibility | Hidden implementation | Full source access |
No Framework Lock-In
The framework code belongs to your project. There is no external dependency to manage, no version constraints to satisfy, no breaking changes forced upon you. If Phexium development stops tomorrow, your project continues unchanged.
Full Transparency
Every framework component is visible and readable. No "black box" behavior hidden in vendor packages. When debugging, you can step through framework code. When learning, you can study the implementation directly.
Local Customization
Modify any framework file to suit your specific needs without maintaining a separate fork:
- Adapt abstractions to your domain
- Change default behaviors
- Extend core components
- Remove features you don't need
Your modifications stay local to your project.
Selective Updates
When Phexium releases updates, you control what enters your project:
# Add upstream as remote (one-time setup)
git remote add upstream https://gitlab.com/phexium/framework.git
# Fetch upstream changes
git fetch upstream
# Review what changed in framework
git diff HEAD upstream/trunk -- src/
# Merge selectively or cherry-pick specific commits
git cherry-pick <commit-hash>
Compare upstream changes against your customizations. Accept improvements that benefit your project. Ignore changes that would conflict with your modifications.
Git-Native Workflow
All framework changes are tracked in your project's Git history:
# Make changes to src/
git diff src/ # Review framework modifications
git add src/
git commit -m "Custom: Extended CommandBus for async support"
You maintain a complete audit trail of customizations. Every modification is documented, reviewable, and reversible.
Directory Structure
The src/ directory contains the Phexium framework core (namespace: Phexium):
src/Application/- Command/Query/Event base classessrc/Domain/- Domain layer interfacessrc/Plugin/- Port & Adapter implementationssrc/Presentation/- Presentation layer interfaces
The app/ directory contains your application code (namespace: App). The demo application provides working examples of framework usage.
Trade-offs
This distribution model requires developers to:
- Understand framework code when making modifications
- Manage merges when incorporating upstream updates
- Take responsibility for framework-level changes
These trade-offs align with Phexium's educational purpose: the framework serves as a learning tool and reference implementation, not a black-box dependency.
When to Modify Framework Code
Consider modifying src/ when:
- Default behavior doesn't fit your domain requirements
- You need to add cross-cutting concerns to base classes
- You want to experiment with architectural variations
Avoid modifying src/ when:
- The change belongs in application code (
app/) - You can achieve the goal through composition or configuration
- The modification would break existing patterns without clear benefit