Product Decisions This Supports

Scalable Domain Modeling: Enables clean implementation of polymorphic entity hierarchies (e.g., Assessment with subtypes Quiz, Survey, Exam) without schema bloat or performance penalties from STI. Critical for platforms with dynamic or evolving data models (e.g., SaaS with customizable workflows, e-commerce with product variants).
Roadmap Justification: Future-proofs architecture for type expansion (adding new subtypes without schema migrations) and multi-tenancy (with custom subtype tables per tenant). Aligns with Laravel’s modular philosophy.
Build vs. Buy: Eliminates ~3–5 weeks of dev effort to build CTI logic from scratch (type resolution, query joins, event handling). Open-source MIT license avoids vendor lock-in.
Key Use Cases:
- Content Management: Articles with subtypes (BlogPost, Newsletter, PressRelease) sharing metadata but with distinct fields.
- FinTech: Instruments (Stock, Bond, Derivative) with shared attributes (ISIN, issuer) and type-specific data.
- Healthcare: Patient records with subtypes (Inpatient, Outpatient) requiring different validation rules.
- Legacy Modernization: Migrating monolithic tables (e.g., orders with nullable shipping_address, billing_address) into normalized CTI schemas.

When to Consider This Package

Adopt If:

Your domain requires strict subtype validation (e.g., "only Quiz can have time_limit").
You need database-enforced referential integrity (foreign keys between parent/subtype tables).
Your team prioritizes developer velocity over micro-optimizations (e.g., avoiding raw SQL for CTI queries).
You’re using Laravel 8–13 + PHP 8.1+ and have moderate-to-high query complexity (e.g., mixed collections, subtype-specific queries).
Your schema is already normalized or you’re willing to refactor for long-term maintainability.
You require seamless integration with Eloquent features (events, relationships, API resources).

Look Elsewhere If:

Your data model is flat (no inheritance hierarchy; STI or single tables suffice).
You need ultra-high-performance bulk operations (this package abstracts queries; raw SQL or STI may outperform for read-heavy workloads).
Your team lacks Laravel/Eloquent expertise (CTI adds complexity to ORM interactions; consider simpler patterns like traits or polymorphic relations).
You require multi-tenancy out of the box (package doesn’t natively support tenant-aware subtype tables; may need customization).
Your subtypes share no attributes (use separate tables with polymorphic relationships instead).

How to Pitch It (Stakeholders)

For Executives/Stakeholders:

*"This package lets us model complex, evolving data structures—like assessments, products, or financial instruments—without technical debt. Instead of cramming all attributes into one table (which gets messy fast), we split shared fields (e.g., title, created_at) into a parent table and type-specific fields (e.g., passing_score for quizzes) into their own tables. The package handles the heavy lifting: automatic type resolution, query optimization, and database integrity.

Why it matters:

Future-proof: Add new subtypes (e.g., Exam, Survey) without schema migrations.
Clean code: No manual SQL joins or N+1 query fixes—just Eloquent magic.
MIT-licensed: Zero vendor risk; fully open-source. Use case: Imagine our [product name] platform where [specific feature, e.g., ‘customizable assessments’]—this package makes that scalable and maintainable."*

For Engineers/Architects:

*"Laravel CTI solves the Class Table Inheritance (CTI) problem natively in Laravel, addressing gaps in Eloquent’s ORM. Here’s how it helps:

Key Benefits:

Automated Type Resolution: Query Assessment::all() and get a mixed collection of Quiz, Survey, etc.—no manual casting.
Zero N+1 Queries: Batch-loads subtype data under the hood (e.g., Quiz::where('passing_score', '>', 90) auto-joins).
Database Integrity: Real foreign keys between parent/subtype tables (vs. STI’s discriminator column).
Eloquent Compatibility: Works with events, relationships, API resources, and Scout indexing.
Flexible Schema: Supports lookup tables or direct discriminators (e.g., type column in parent table).

Tradeoffs:

Slightly higher initial setup (schema design, model configuration).
Writes touch multiple tables (wrapped in transactions by the package).

When to Use:

Replace STI: If your table has >10 nullable columns or you’re adding new subtypes often.
Avoid Polymorphic Relations: If subtypes are parents (e.g., Quiz is an Assessment), not just related entities.
Legacy Refactoring: Normalize monolithic tables (e.g., orders with nullable shipping_address).

Example:

// Parent model
class Assessment extends Model {
    use HasSubtypes;
    protected static $subtypeMap = ['quiz' => Quiz::class];
}

// Subtype model
class Quiz extends SubtypeModel {
    protected $subtypeTable = 'assessment_quiz';
    protected $subtypeAttributes = ['passing_score'];
}

// Usage
$quiz = Quiz::create(['title' => 'Final', 'passing_score' => 80]);
$all = Assessment::all(); // Returns mixed collection of Quiz, Survey, etc.

Next Steps:

Pilot: Test with a non-critical module (e.g., a new assessment type).
Benchmark: Compare query performance vs. STI/polymorphic relations.
Document: Add CTI patterns to our architecture guidelines.

This is a high-leverage tool for [specific goal, e.g., ‘scaling our assessment engine’] with minimal long-term maintenance."*

Laravel Cti Laravel Package