Orm Laravel Package

Product Decisions This Supports

• Build vs. Buy: Accelerates development by eliminating the need to build a custom data mapper layer for persistence models, reducing technical debt and maintenance overhead.
• Architecture Alignment: Enables a clean separation between domain models (business logic) and persistence models (data storage), adhering to DDD principles and improving long-term maintainability.
• Roadmap Prioritization:
  • MVP Launch: Speeds up CRUD-heavy features (e.g., admin panels, reporting dashboards) by abstracting database interactions.
  • Scalability: Supports gradual migration from simple records to rich domain models as the product matures, avoiding premature abstraction.
  • Multi-Database Support: If future plans include switching databases (e.g., PostgreSQL → MySQL), Atlas’s data-mapper pattern isolates persistence logic, easing migration.
• Use Cases:
  • Legacy System Integration: Rapidly map existing database schemas to PHP objects without coupling business logic to SQL.
  • API Backends: Efficiently handle read/write operations for REST/GraphQL APIs where domain logic is minimal or decoupled.
  • Data Pipelines: Process bulk data (e.g., imports/exports) where domain validation is secondary to persistence efficiency.

When to Consider This Package

Adopt if:

• Your team prioritizes separation of concerns (domain vs. persistence) and wants to avoid Active Record patterns (e.g., Eloquent’s model-table coupling).
• You’re building a CRUD-heavy application (e.g., CMS, SaaS admin panels) where domain logic is thin, but data operations are frequent.
• You need flexibility to change databases later without rewriting business logic.
• Your team values explicit mappings (e.g., mapping a UserRecord to a User domain object) over "magic" ORMs.
• You’re already using Laravel but want to avoid Eloquent’s tight coupling to Laravel’s ecosystem (e.g., for non-Laravel microservices).

Look elsewhere if:

• Your application is heavily domain-driven (e.g., complex business rules, transactions) and requires an ORM that tightly integrates with domain logic (e.g., Doctrine ORM or Eloquent).
• You need advanced features like:
  • Second-level caching (consider Doctrine Cache).
  • Complex inheritance mapping (Atlas is schema-first; Doctrine handles this better).
  • Multi-tenancy or soft deletes (may require custom extensions).
• Your team lacks experience with data-mapper patterns and prefers convention-over-configuration (e.g., Eloquent).
• The project has no clear separation between persistence and domain layers (Atlas enforces this discipline).
• Last release was 2021: If long-term maintenance is critical, evaluate alternatives with active development (e.g., Cycle ORM, RedBeanPHP).

How to Pitch It (Stakeholders)

For Executives: *"Atlas.Orm is a lightweight, MIT-licensed ORM that lets us build data-heavy features faster by automating database interactions—without locking us into a single database or ORM. It’s ideal for our [MVP/admin panel/API] roadmap because it:

• Reduces dev time by handling CRUD boilerplate (e.g., saving/loading records).
• Future-proofs our architecture by separating domain logic (our competitive edge) from persistence details.
• Aligns with Laravel’s ecosystem while avoiding Eloquent’s tight coupling, giving us flexibility if we spin out non-Laravel services later. Think of it as ‘Laravel’s Eloquent, but for data plumbing—not business logic.’ It’s a low-risk bet with minimal ongoing costs."*

For Engineering: *"Atlas is a data mapper (not an Active Record ORM like Eloquent), meaning:

• No ‘magic’: Explicitly map database tables to PHP records (e.g., UserRecord → User domain object). No surprises.
• Laravel-compatible: Works alongside Laravel’s ecosystem but doesn’t force us into Eloquent’s patterns.
• Lightweight: ~400 stars, MIT license, and minimal overhead. Perfect for:
  • Rapidly prototyping CRUD interfaces.
  • Decoupling persistence from domain models (good for DDD).
  • Projects where we might switch databases later. Downside: Last release was 2021, so we’d need to vet stability for critical paths. But for [use case X], it’s a clear win over writing raw SQL or using Eloquent for everything.* Alternatives: Doctrine (overkill for simple cases), Eloquent (tighter coupling), or raw SQL (higher maintenance)."*

For Developers: *"Atlas lets you treat database tables like dumb data containers (records) that you populate into rich domain objects. Example:

// Persistence layer (Atlas Record)
$userRecord = new UserRecord(['name' => 'Alice']);
$userRecord->save();

// Domain layer (your business logic)
$user = new User($userRecord->toArray());
$user->validate(); // Your domain rules here

Why it’s useful:

• Avoids Eloquent’s ‘model = table’ coupling.
• Easy to swap databases later (e.g., MySQL → PostgreSQL).
• Great for admin panels or APIs where domain logic is separate. Tradeoff: Less ‘batteries-included’ than Eloquent (e.g., no built-in relationships). But that’s a feature if you want control!"*