Bagisto Hosting

Understanding Contracts in Bagisto: The Foundation Behind Model Overrides

Updated 14 July 2026

Introduction

Bagisto Contracts are one of the core concepts behind Bagisto’s extensible architecture.

If you’ve explored the Bagisto source code, you’ve probably noticed that every major entity, such as Product, Category, or Customer, contains three files:

Most developers immediately understand the Model, but the purpose of the Contract and Proxy is often less obvious.

We’ve already covered the Proxy Pattern in detail in our previous article:

Bagisto Proxy Pattern for Model Override
https://bagisto.com/en/bagisto-proxy-pattern-model-override/

In this article, we’ll focus on the missing piece of the puzzle.

The Contract—and see how Bagisto combines Laravel Contracts, Concord, and Proxies to create an upgrade-safe architecture.

Laravel’s Approach to Bagisto Contracts

Laravel encourages developers to depend on abstractions rather than concrete implementations.

Instead of tightly coupling your application to a specific class.

Laravel allows you to depend on an interface that can later be resolved into the appropriate implementation.

Bagisto follows the same principle for its core models.

Instead of directly depending on the Product model, repository depend on the Product Contract.

The repository doesn’t know which Product model it will receive. It only knows it needs something that satisfies the Product contract.

Laravel vs Bagisto Model Resolution

Bagisto Contracts vs Laravel model resolution architecture

The Three Components of Bagisto Contracts

Each Bagisto model consists of three independent components.

1. Contract

Defines what the model represents.

Bagisto Contracts act as the abstraction that repositories and services depend on.

2. Model

Provides the actual Eloquent implementation.

This class contains relationships, scopes, business logic, and database interaction.

3. Proxy

The Proxy is mainly used by Eloquent relationships where Laravel expects a model class instead of an interface.

Since we’ve already covered the Proxy Pattern in detail, we won’t dive deeper here. You can read the complete explanation in our previous blog.

How Bagisto Resolves the Contract

Bagisto Contracts cannot interact with the database directly.

Instead, Konekt Concord maintains the mapping between a Contract and its registered model.

The resolution flow looks like this:

Contract Resolution in Bagisto

Bagisto Contracts resolved by Concord

Whenever a repository requests the Product Contract, Concord returns the currently registered Product model.

Why Doesn’t the Repository Use ProductProxy?

This is one of the most common questions.

Repositories work with Contracts, not Proxies.

The reason is simple:

For example:

Contracts and Proxies Working Together

Bagisto Contracts and Proxies working together

The repository and the relationship solve two different problems, which is why they use different components.

Why Bagisto Contracts Matter

This separation is one of the biggest advantages of Contracts.

If you create your own Product model and register it with Concord.

Every repository automatically begins using your implementation without requiring changes to the framework.

Similarly, relationships continue to work because they resolve the registered model through the Proxy.

The result is a flexible, upgrade-safe architecture that allows developers to customize core models without editing vendor files.

Conclusion

Bagisto’s architecture is built around three simple ideas:

Together with Concord, Bagisto Contracts allow developers to customize core models without modifying vendor files.

. . .

Leave a Comment

Your email address will not be published. Required fields are marked*


Be the first to comment.

Start a Project




    Message Sent!

    If you have more details or questions, you can reply to the received confirmation email.

    Back to Home