Don't subsume
Authentication, validation, and ORM are not bundled in. The framework provides constraints; libraries remain choosable. The freedom to choose standards is preserved.
Architecture
Don't hide the design behind the implementation.
BEAR.Sunday treats Web constraints as design principles for the interior of the application. Resource, DI, AOP, and Context divide responsibilities, making code meaning readable and producing a structure that withstands long-term operation.
Design philosophy
Connect each thing, as itself.
BEAR.Sunday doesn't absorb necessary technologies and rebuild them inside itself. SQL stays SQL. Validation stays JSON Schema. Links stay HAL. The more important the commitment, the more it follows published standards rather than framework-specific inventions. By letting each do its job, harmony—not tension—emerges.
Connect independently
JSON Schema, HAL, OpenAPI, SQL, and PSR are used in forms that remain valid outside BEAR.Sunday. Your investment isn't locked into the framework.
Follow standards for what matters
Validation uses JSON Schema. Links use HAL. API descriptions use OpenAPI. The more critical the part, the more it's expressed in published standards rather than custom syntax. That's why it's documented, long-lasting, and directly usable by other tools and AI.
Harmony, not tension
SQL isn't made to pretend to be objects. Each does what it does best. Without forced abstractions, there's no friction at the seams.
Give one job to the connection point, pass by type, hide the other side. That's why it's replaceable and long-lasting. This is not a feature—it's a design philosophy, an aesthetic.
Resource Oriented Architecture
Design application entry points as URI-identifiable resources, not pages or controllers. State, links, and representation boundaries align, allowing Web API, HTML, and CLI to share the same meaning.
Dependency Injection
Ray.Di, which evolves Google Guice concepts for PHP, resolves dependencies using types and Qualifiers as Keys. Modules declare bindings; the Injector generates the object graph.
Aspect Oriented Programming
Cross-cutting concerns like caching, transactions, logging, and authorization are separated as Interceptors. Resource classes can focus on application meaning.
Context
Context strings like prod-hal-api-app combine environment, representation, and application type. Environment branching is kept out of application code; differences are expressed in DI modules.
Context Agnostic Objects
Context is only used during object graph generation. Once created, objects don't know which context they were built for. References to execution modes like APP_DEBUG are structurally eliminated.
ADP Package Structure
Both framework packages and applications are structured to avoid circular dependencies. Multiple applications are integrated via namespace and DI binding instead of HTTP boundaries, and can be called as resources from other PHP applications.
Resource discipline
A Resource is not a place to write anything.
BEAR.Sunday's resource orientation is not about creating URL-callable components. It's a constraint that determines where application meaning is placed, and from there unfolds representation and connections outward.
Place meaning in the Resource
Place the meaning of functionality in the Resource. Representation, dependencies, transitions, caching, and documentation unfold outward from there.
Govern yourself, don't manipulate others
Resource methods are not a place to manipulate external response objects. They decide their own state and return themselves.
Have no concern for representation
Resources hold values, state, and links. HTML, JSON, and CLI representation is the renderer's concern; the Resource doesn't know about representation.
Declare In / Out through constraints
Input is declared through method signatures, types, attributes, and schemas. Output is also left as body, headers, links, and schema—not buried in implicit display concerns.
Ray.Di and Guice
Dependency resolution is declared graph generation, not runtime lookup.
At Ray.Di's center lies thinking derived from Google Guice. Application code doesn't go fetch dependencies—it declares what it needs in the constructor. Modules define bindings like "this Key → this Provider," and the Injector traces dependencies-of-dependencies to assemble the object graph before execution.
That's why BEAR.Sunday's DI is not convenient auto-wiring. It treats context, binding, scope, and interceptors as object graph composition, and eliminates the ability of post-construction objects to reference configuration information.
Key
Dependencies are identified by type and Qualifier attributes. The same interface can have distinct implementations for payments, logging, and testing without confusion.
Module
A configuration unit that collects bindings. Combine Modules by feature, environment, and representation to create object graphs suited to each context.
Provider
Handles complex creation, lazy initialization, and mixed scopes. Consumers declare only what they need, without knowing how it's created.
Scope
Lifecycle control (prototype, singleton, etc.) is managed on the binding side. Objects themselves don't need to know their own lifespan.
Interceptor
AOP Alliance-style MethodInterceptors separate transactions, authorization, and caching from the main code.
Compiler
Generates PHP factory code from the dependency graph, reducing container initialization overhead in production. The generated output has a traceable structure.
Resource flow
From request to representation, carrying the same meaning.
Rather than dividing by role names like MVC, state and links are gathered around the resource. Rendering and transport are separated outward, so the resource preserves what it is.
01
Request: app://self/profile?id=1
02
Resource: Profile::onGet(int $id)
03
Body: holds state as an array or value object
04
Links: declares navigability via HAL or attributes
05
Renderer: converts representation to HTML, JSON, HAL, or CLI
Long-term structure
Change goes to modules. Resource meaning is preserved.
Express environment differences through context modules
Post-construction objects don't know their context
Swap representation formats via renderers
Apply cross-cutting concerns via interceptors
Integrate multiple apps without HTTP walls
Call BEAR resources from other PHP apps
Start with one resource