Model Shared Laravel Package

Product Decisions This Supports

• Adopt vs. rebuild shared domain models: The package provides ready-made Laravel models and migrations for common zakat/charity entities: occupation, education level, marital status, Indonesian administrative regions (country → province → regency/city → district → village), donor, bank, donation, funding category/type, partner, and outflows. Release 2.10.6 adds further models (specifics are not enumerated in the release notes — confirm against PR #46 before planning around them). A PM can use this to avoid funding duplicate model/migration work across apps.
• Build vs. integrate: Treat this as “integrate” for commodity/reference data and shared domain tables; reserve “build” for product-specific workflows such as donor segmentation, campaign logic, zakat calculation, payment orchestration, and reporting UX.
• Scope trend / roadmap sequencing: The package's model surface is still growing, which reinforces its role as the shared data backbone rather than a finished product. Plan for the schema to expand between minor versions and budget for periodic compatibility checks. It supports faster delivery of donor profile/contact features (phone, email, notifications), branch/employee attribution through dynamic relations, donation/funding categorization, partner management, and disbursement/outflow tracking.
• Multi-product consistency: Most valuable if the organization runs multiple Laravel apps or back-office systems that must agree on donor, donation, funding, and Indonesian region definitions. Each new model added upstream shrinks the set of tables each app must define independently.
• Compliance and reporting: Village-level geographic data and standardized donor/payment structures reduce data cleanup for distribution and regulatory reporting in Indonesia.
• MVP and internal tooling: Useful for admin panels, data-entry tools, and reporting MVPs where core reference tables would otherwise slow down discovery-to-delivery.

When to Consider This Package

• Consider adoption when:

  • You are building Laravel applications in the Inisiatif Zakat Indonesia ecosystem or a similar Indonesian zakat/charity domain.
  • You need shared reference models for Indonesian administrative regions, education, occupation, marital status, and common donor/donation/funding entities — and any newly added models that map to your domain.
  • You have multiple apps or teams that would otherwise duplicate models, migrations, and lookup data.
  • You can pin a version (note: minor releases such as 2.10.6 still introduce new models and migrations), assign an internal owner, and test Laravel/database compatibility.
  • You want flexible Donor→Branch/Employee relations via resolveRelationUsing without hard-coding app-specific models into the package.

• Look elsewhere or build custom when:

  • You need a broadly supported public package with strong community validation; 0 stars and 0 dependents signal internal/early adoption, not ecosystem maturity — active commits are a positive maintenance signal but not external validation.
  • Your domain is global or non-Indonesian, or you need live/official region-boundary updates.
  • Your schema requires substantial donor-specific customization or a non-Laravel ORM.
  • You need vendor SLAs, public documentation, or guaranteed long-term maintenance.
  • You are a single app that can define a few tables directly; this package’s value comes primarily from reuse across apps.
  • Compatibility with your Laravel/PHP version, migration order, UUID/ID conventions, and table naming has not been verified — re-verify on each minor bump, since new models arrive with new migrations.

How to Pitch It (Stakeholders)

Executives: Position it as an internal accelerator and data-standardization asset, not a strategic public open-source dependency. If we build multiple Laravel zakat applications, adopting it can reduce duplicate model/migration work, speed donor/disbursement/admin feature delivery, and align reporting on Indonesian regions and donor records. Recent releases (2.10.6) show continued internal investment — the model coverage keeps expanding — which is a positive maintenance signal but also means the schema is a moving target. Recommend a time-boxed pilot in one app with version pinning and an internal owner. Success measures: model/migration effort avoided, faster feature cycle time, fewer cross-app data mismatches. Main risk: low external adoption and small community; treat it as an owned dependency and budget maintenance plus per-release upgrade review.

Engineering/product leads: It is a Composer package of shared Eloquent models, migrations, and a service provider, with dynamic relations for app-specific links such as Donor→Branch/Employee and a region search API. Release 2.10.6 is a non-breaking additive release adding new models via PR #46 — review the diff to see which entities are now available, and whether they overlap or conflict with tables you already maintain. Use it for reference/common domain tables; extend in app code via dynamic relations or subclassing rather than forking unless necessary. Validate Laravel compatibility, migration ordering, ID/UUID strategy, and upgrade path, and add integration tests around package tables. Good fit for internal multi-app standardization; weak fit for public, global, or highly customized products.