diff --git a/manuals/1.0/en/15.tech.md b/manuals/1.0/en/15.tech.md index 3c5efb0e..fe93b7ec 100644 --- a/manuals/1.0/en/15.tech.md +++ b/manuals/1.0/en/15.tech.md @@ -4,274 +4,194 @@ title: Technology category: Manual permalink: /manuals/1.0/en/tech.html --- - # Technology -This chapter explains the features and technical characteristics of BEAR.Sunday. +This chapter explains the unique features and technologies of BEAR.Sunday. ## Architecture and Design Principles -### Resource Oriented Architecture (ROA) - -> "Resources interconnected, like the web of life that binds all creatures." +### Resource-Oriented Architecture (ROA) -BEAR.Sunday's ROA is an architecture for implementing RESTful APIs within web applications. It is the core of BEAR.Sunday's design principles and serves as both a hypermedia framework and an "object as a service". Just like the Web, all data and functions are treated as resources and are manipulated through standardized interfaces such as GET, POST, PUT, and DELETE. +BEAR.Sunday's ROA is an architecture for implementing RESTful APIs within web applications. It is the core of BEAR.Sunday's design principles, serving as both a hypermedia framework and a way to treat "objects as services." Like the Web, all data and functions are considered resources and are manipulated through standardized interfaces such as GET, POST, PUT, DELETE, etc. #### URI -URI (Uniform Resource Identifier) is a key element to the success of the Web and is also at the heart of BEAR.Sunday's ROA. By assigning URIs to all resources handled by the application, resources become identifiable and easily accessible. URIs serve not only as identifiers for resources but are also used to express relationships between resources. This facilitates the manipulation, reuse, and combination of resources. +URI (Uniform Resource Identifier) is a key element to the success of the Web and is also at the core of BEAR.Sunday's ROA. By assigning URIs to all resources handled by the application, resources can be identified and easily accessed. URIs not only function as identifiers for resources but are also used to express relationships between resources. #### Uniform Interface -Access to resources is done using HTTP methods (GET, POST, PUT, DELETE). These methods define the operations that can be performed on resources and provide a common interface regardless of the type of resource. - -- GET: Retrieves the current state of a resource -- POST: Performs a non-idempotent operation on a resource (e.g., creation) -- PUT: Performs an idempotent operation on a resource (e.g., creation or update) -- DELETE: Deletes a resource +Access to resources is done using HTTP methods (GET, POST, PUT, DELETE). These methods specify the operations that can be performed on a resource and provide a common interface regardless of the type of resource. #### Hypermedia -In BEAR.Sunday's ROA, each resource provides affordances (available operations or functions for the client) through hyperlinks. These links represent the operations available to the client and provide instructions on how to navigate within the application. This reduces the coupling between the client and server and increases the flexibility and extensibility of the application. - -Hyperlinks not only indicate relationships between resources but also function as a mechanism to embed resources. This is similar to how images are embedded in HTML using the IMG tag. In BEAR.Sunday, resources are accessible as independent entities, and relationships between resources are declaratively constructed through internal links, forming a tree structure of content. - -BEAR.Sunday's hypermedia approach aligns with the principles of the Web and enhances the flexibility and extensibility of applications. +In BEAR.Sunday's ROA, each resource provides affordances (operations and functions available to the client) through hyperlinks. These links represent the operations available to the client and provide instructions on how to navigate within the application. #### Separation of Value and Representation -In BEAR.Sunday's ROA, the value and representation of resources are clearly separated. The value of a resource is managed by the application's domain logic, while the representation is used to present that value in various formats (JSON, XML, HTML, etc.). This separation results in loose coupling between domain logic and presentation logic, improving the maintainability and extensibility of the application. - -#### Page Resources and App Resources - -In BEAR.Sunday's ROA, resources are classified into two categories: page resources and app resources. - -- Page Resources: Primarily resources with HTML representation, intended to be accessed from web browsers. These resources constitute the user interface. -- App Resources: Resources that make up the application's backend, primarily using JSON or XML representations. They are intended to be accessed by other applications or services. - -Separating page resources and app resources allows independent development and deployment of the user interface and application logic. Additionally, by reusing app resources, a consistent backend can be provided to multiple user interfaces (web browsers, mobile apps, other services, etc.). - -Using BEAR.Sunday's ROA, scalable and loosely coupled applications can be built in alignment with the design principles of the Web. The separation of value and representation allows independent development and testing of domain logic and presentation logic, improving application quality and development efficiency. Furthermore, separating page resources and app resources enables independent development and deployment of the user interface and application logic, enhancing the flexibility and extensibility of the application. Hyperlinks also make the relationships between resources explicit, keeping coupling between the client and server low while enhancing the self-descriptiveness and discoverability of APIs. +In BEAR.Sunday's ROA, a resource's value and representation are clearly separated. Resource values are managed by the application's domain logic, while representations are for expressing those values in various formats (JSON, XML, HTML, etc.). This separation results in loose coupling between domain logic and presentation logic. #### Differences from MVC -BEAR.Sunday's ROA takes a different approach compared to the traditional MVC architecture. MVC composes an application with three components: Model, View, and Controller. In practice, however, the Controller freely manipulates the Model and View at runtime, with the Controller literally controlling everything. - -In contrast, in BEAR.Sunday, the View is injected into the resource object. The resource is oblivious to the View, and the View is also oblivious to the resource. The resource object does not perform operations on the injected View and does not even know what kind of View has been injected. While the resource's methods are only concerned with the resource state, the injected resource View renders the resource's state into a string representation only when the resource object is string-evaluated. In this way, the resource and View are loosely coupled, and their responsibilities are clearly separated. +BEAR.Sunday's ROA takes a different approach from the traditional MVC architecture. MVC composes an application with three components: Model, View, and Controller. In contrast, BEAR.Sunday injects views into resource objects. Resources and views are loosely coupled, with their responsibilities clearly separated. -Furthermore, unlike the relationship between the Controller and Model where there are no constraints, resources have constraints on including other resources using URIs, and this can be done declaratively. That resource depends on another resource, forming a tree structure like DI dependencies. Other differences include: +Also, in contrast to the lack of constraints on the relationship between controllers and models, resources have constraints on including other resources using hyperlinks and URIs, and this can be done declaratively. -- BEAR.Sunday's resources provide possible operations (affordances) by declaring relationships. They are self-descriptive. -- HAL (Hypertext Application Language) is adopted to standardize links between resources. -- Unlike MVC models, resources can be directly called from a variety of clients, including the console. -- There is no need to build HTML sites and API sites separately; both HTML sites and API sites can be built simultaneously using the same resources. +Unlike MVC models, resources can be directly called from diverse clients including the console, and there are differences such as being able to simultaneously build HTML sites and API sites using the same resources without needing to construct HTML sites and API sites separately. ### Dependency Injection (DI) -> "Objects are injected from the interface, just as sun rays are injected when a window is opened." - Dependency Injection (DI) is an important technique for enhancing the design and structure of applications in object-oriented programming. The central purpose of DI is to divide an application's functionality into multiple components with independent domains or roles and manage the dependencies between them. -DI helps horizontally divide a single function into multiple functions. The divided functions can be independently developed and tested as "dependencies" with clear responsibilities and roles based on the single responsibility principle. Injecting those dependencies from the outside, with clear responsibilities and roles, improves the reusability and testability of objects. Dependencies are also vertically divided into other dependencies, forming a dependency tree. This dependency tree is called an object graph, and the main role of DI is to become the builder of this object graph. - -Using DI improves the structure of the application and loosens the coupling between components. This helps adhere to many of the best practices in object-oriented programming, resulting in code that is manageable and testable. However, these are merely secondary benefits, and the primary purpose of DI is to design and build loosely coupled applications following the principle of "divide and conquer". +DI helps horizontally split a single function into multiple functions. The split functions can be independently developed and tested as "dependencies." Based on the single responsibility principle, by injecting those dependencies with clear responsibilities and roles from the outside, it improves object reusability and testability. Dependencies are also vertically split into other dependencies, forming a tree of dependencies. -BEAR.Sunday's DI uses an independent package called [Ray.Di](https://github.com/ray-di/Ray.Di), which adopts the design philosophy of Google's DI framework, Guice, and covers almost all of its features. +BEAR.Sunday's DI uses a separate package called [Ray.Di](https://github.com/ray-di/Ray.Di), which incorporates the design philosophy of Google's DI framework Guice and covers almost all of its features. -#### Context-based Binding +Other features include: -For example, consider an application with a base application and two contexts: HTML and PROD. In the HTML context, the JSON view bound to the resource representation changes to an HTML view binding. In PROD, the Array cache interface bound to the cache interface is bound to the Redis cache. By layering the bindings of multiple contexts, the application can exhibit different behaviors without changing the application code. - -Instead of using IF statements to check if it is in DEBUG mode and change the behavior at runtime, different implementations are bound according to the context. - -Other characteristics include: - -* The self-descriptiveness of the code is enhanced through attribute-based configuration. -* The self-descriptiveness of the code is further enhanced by using qualifiers to bind different implementations to the same interface. -* Ray.Di resolves dependencies at compile time, improving runtime performance. This is different from other DI containers that resolve dependencies at runtime. -* The dependency graph of objects can be visualized. For example, [Application Skeleton](/images/app.svg). -* In addition to link binding, instance binding, and other bindings, there are also attribute binding, untarget binding, multi-binding, construct binding, context binding, null binding, and various other bindings supported. -* For dependencies with a large cost for instantiation, lazy binding can be used to obtain instances at runtime. -* Bindings can be grouped into modules for reuse. +* Bindings can be changed based on context, allowing different implementations to be injected during testing. +* Configuration via attributes increases code self-descriptiveness. +* Ray.Di resolves dependencies at compile-time, improving runtime performance. This differs from other DI containers that resolve dependencies at runtime. +* Object dependencies can be visualized as a graph. Example: [Application Skeleton](/images/app.svg) Ray.Di logo ### Aspect-Oriented Programming (AOP) -> "Aspects wrap your objects, like a gift wrap enhances a present." - -Aspect-Oriented Programming (AOP) is a pattern for achieving flexible applications by separating core concerns, such as business logic, from cross-cutting concerns, such as logging and caching. Cross-cutting concerns refer to functionality or processing that spans multiple modules or layers. +Aspect-Oriented Programming (AOP) is a pattern that enables flexible applications by separating core concerns such as business logic from cross-cutting concerns such as logging and caching. Cross-cutting concerns refer to functions or processes that span multiple modules or layers. Binding of cross-cutting processes based on search conditions is possible, allowing for flexible configurations based on context. -BEAR.Sunday's AOP uses an independent package called Ray.Aop, which declaratively binds cross-cutting processing by attaching PHP attributes to classes or methods. Ray.Aop conforms to Java's [AOP Alliance](https://aopalliance.sourceforge.net/) and has the following characteristics: +BEAR.Sunday's AOP uses a separate package called Ray.Aop, which declaratively binds cross-cutting processes by attaching PHP attributes to classes or methods. Ray.Aop adheres to Java's [AOP Alliance](https://aopalliance.sourceforge.net/) and has the following characteristics. -* The declarative description method using attributes improves code readability. -* Cross-cutting processing can be bound based on search conditions, allowing flexible configuration based on context. - -AOP is one of the most misunderstood technologies. Its raison d'être is not to ignore constraints and disrupt order for the sake of powerful capabilities. Instead, it is one of the paradigms that complements areas where object-oriented programming is not well-suited, such as exploratory feature assignment and separation of cross-cutting concerns, and makes it possible to design application-wide constraints, i.e., constraints as an application framework. +AOP is one of the most misunderstood technologies. Its purpose is never to break order for the sake of powerful capabilities, but rather to complement areas where object-orientation struggles, such as the exploratory assignment of functionality using matchers and the separation of cross-cutting processes. AOP is a paradigm that functions as an application framework by creating cross-cutting constraints for applications. ## Performance and Scalability -### ROA-based Event-driven Content Strategy Integrated with Modern CDNs - -> "No volatility, just what users truly desire." +### ROA-based Event-Driven Content Strategy with Modern CDN Integration -BEAR.Sunday achieves an advanced event-driven caching strategy by integrating with instant-purgeable CDNs such as Fastly, with Resource-Oriented Architecture (ROA) at its core. Instead of invalidating caches based on traditional TTL (Time to Live), this strategy instantly invalidates CDN and server-side caches, as well as ETags (Entity Tags), in response to resource state change events. +BEAR.Sunday achieves an advanced event-driven caching strategy by integrating with instant-purgeable CDNs like Fastly, with its Resource-Oriented Architecture (ROA) at the core. Instead of traditional cache invalidation based on Time to Live (TTL), this strategy immediately invalidates the CDN, server-side cache, and ETag (Entity Tag) based on resource state change events. -This approach, which eliminates volatility, not only avoids SPOF (Single Point of Failure) and achieves high availability and fault tolerance but also maximizes user experience and cost efficiency. It realizes the same distributed caching of the Web for dynamic content as for static content, which the Web has had since the 1990s. In other words, it re-implements the principle of distributed caching, which scales and reduces network costs, using modern technologies. +This approach, which eliminates volatility, not only avoids Single Point of Failure (SPOF) and achieves high availability and fault tolerance but also maximizes user experience and cost efficiency, realizing the Web's original distributed caching for dynamic content just like static content. It re-implements the scalable and network cost-reducing distributed caching principles that the Web has had since the 1990s using modern technologies. #### Cache Invalidation through Semantic Methods and Dependencies -In BEAR.Sunday's ROA, each resource operation is assigned a semantic (meaningful role). For example, the GET method retrieves a resource, while the PUT method updates a resource. These methods collaborate in an event-driven manner to efficiently invalidate related caches. For instance, when a specific resource is updated, the caches of resources that depend on that resource are invalidated. This ensures data consistency and freshness, providing users with the latest information. +In BEAR.Sunday's ROA, each resource operation is given a semantic (meaningful role). For example, the GET method retrieves a resource, while the PUT method updates a resource. These methods work together in an event-driven manner to efficiently invalidate related caches. For instance, when a specific resource is updated, the cache of resources that require that resource is invalidated. This ensures data consistency and freshness, providing users with the latest information. -#### Identity Verification and Quick Response using ETag +#### Rapid Response with ETag for Identity Verification -By setting ETag before the system boots, the identity of the content can be quickly verified, and if there are no changes, a 304 Not Modified response is returned. This is an effective technique for reducing network load and improving user experience. +By setting the ETag before the system boots, content identity can be quickly verified, and if there are no changes, a 304 Not Modified response is returned to minimize network load. #### Partial Updates with Donut Caching and ESI -BEAR.Sunday adopts a donut caching strategy and uses Edge Side Includes (ESI) to enable partial content updates at the CDN edge. This technology allows dynamic updates of only the necessary parts without re-caching the entire page, significantly improving performance and caching efficiency. +BEAR.Sunday adopts the donut caching strategy and uses ESI (Edge Side Includes) to enable partial content updates at the CDN edge. This technology allows dynamic updates of only the necessary parts without re-caching the entire page, improving caching efficiency. -Thus, the ROA-based caching strategy integrated with Fastly and BEAR.Sunday not only realizes advanced distributed caching but also enhances application performance and fault tolerance. This allows users to experience consistent responsiveness and data integrity under any circumstances. +In this way, BEAR.Sunday's ROA-based caching strategy integrated with Fastly not only achieves advanced distributed caching but also improves application performance and enhances fault tolerance. -### Boot Acceleration +### Faster Startup -In the world of DI, users ideally do not directly deal with the injector (DI container) as much as possible. Instead, at the application's entry point, a single root object is created to start the application. In BEAR.Sunday's DI, there is essentially no DI container manipulation even at configuration time. The root object is huge but a single variable, so it is reused across requests to achieve an extremely optimized bootstrap. +In the original world of DI, users avoid dealing with the injector (DI container) directly as much as possible. Instead, the application is started by creating a single root object at the application's entry point. In BEAR.Sunday's DI, there is essentially no DI container manipulation even during configuration. The root object is huge but is a single variable, so it is reused across requests to realize a highly optimized bootstrap. ## Developer Experience ### Ease of Testing -BEAR.Sunday facilitates easy and effective testing due to the following design characteristics: - -* Each resource is independent, and the stateless request nature of REST makes testing straightforward. -* With the separation of resource state and representation, it is possible to test the resource state even when using HTML representation. -* API testing can be performed by following hypermedia links, using the same code in PHP and HTTP. -* Context-based binding allows binding different implementations during testing. Bindings can be changed for the entire "test context" or temporarily for a specific test. -* ResourceObject includes `header` meta-information, enabling testing based on meta-information. For example, if the content is cached, the presence or absence of caching can be tested by checking the `Age` header. Compare this to MVC models. -* Resources embedded with `#[Embed]` embed resource requests, not values. The intention of what kind of resource to embed can be tested. - -### Visualization and Debugging +BEAR.Sunday allows for easy and effective testing due to the following design characteristics: -* During development, the scope and tools of resources are displayed graphically on HTML. -* Resource states can be checked on the web interface, and PHP code and HTML templates can be edited online and reflected in real-time. +- Each resource is independent, and the stateless request nature of REST makes testing straightforward. +- Since resource state and representation are separated, it is possible to test the resource state even when using HTML representation. +- API testing can be performed by following hypermedia links, using the same PHP and HTTP code for testing. +- Different implementations can be bound for testing through context-dependent binding. ### API Documentation Generation -API documentation is automatically generated from the code. This maintains consistency between the code and documentation, enhancing maintainability. +API documentation is automatically generated from code, maintaining consistency between code and documentation and improving maintainability. -## Extensibility and Integration +### Visualization and Debugging -### Resource Validation +By leveraging the technical feature of resources rendering themselves, during development, the scope of resources can be indicated on HTML, resource states can be monitored, and PHP code and HTML templates can be edited in an online editor and reflected in real-time. -Resource representations are validated using JsonSchema to maintain resource consistency. Using standard schemas for validation allows the use of external tools. +## Extensibility and Integration ### Integration of PHP Interfaces and SQL Execution -In BEAR.Sunday, PHP interfaces can be used to easily manage the execution of SQL statements for interacting with the database. Instead of implementing classes, SQL execution objects can be directly bound to PHP interfaces. This improves code reusability and enhances modularity. - -### Query Argument Evaluation +In BEAR.Sunday, SQL statements for interacting with databases can be easily managed using PHP interfaces. SQL execution objects can be directly bound to PHP interfaces without implementing classes. The boundary between the domain and infrastructure is connected by PHP interfaces. -PHP interfaces bound to SQL execution can accept not only scalar values but also objects as arguments. For example, if there is a DateTimeInterface argument, the bound current time is automatically evaluated as a date string to be properly handled as a date within the SQL statement. The self-resolving PHP interface reduces the burden of resolving arguments passed to SQL and improves code readability. +Arguments can also be typed, and any missing arguments are resolved by DI and used as strings. Even when the SQL execution requires the current time, there is no need to pass it explicitly; it is automatically bound. This helps keep the code concise as the client is not responsible for passing all arguments. -#### SQL Generation and Optimization using AI and Tools - -In BEAR.Sunday, dependencies can also be injected into interfaces. This allows necessary objects and values to be dynamically supplied to interfaces, enabling more flexible application design. Using dependency injection makes code testing easier, maintaining low coupling while achieving high cohesion. - -### Comprehensive Debugging and Maintenance Convenience - -The direct management of SQL facilitates debugging when errors occur. The behavior of SQL queries can be directly observed, allowing quick identification and correction of problems. Additionally, query modifications and feature extensions can be performed directly, making application maintenance and evolution smooth. - -* PHP interfaces and SQL can be prepared, and SQL execution objects can be bound to PHP interfaces without implementing classes. -* PHP interfaces can accept not only scalar values but also objects to be evaluated as strings. For example, specifying DateTimeInterface will evaluate it as a date in SQL. -* Dependencies can be injected as arguments into PHP interfaces. +Direct management of SQL also facilitates debugging when errors occur. The behavior of SQL queries can be directly observed, allowing for quick identification and correction of issues. ### Integration with Other Systems -* Integrate with console applications to make all resources accessible from both the web and command line without changing the source code. -* Different applications can be executed concurrently within the same PHP runtime, making all resources accessible from an HTTP client. -* Local and remote BEAR.Sunday applications can be treated similarly, and BEAR.Thrift enables integration with applications in other languages. +Integration with console applications allows access from both the Web and command line without changing the source code. Also, by enabling the concurrent execution of different BEAR.Sunday applications within the same PHP runtime, multiple independent applications can be coordinated without building microservices. ### Stream Output -* By streaming the representation of resources, large-scale content that cannot be handled in memory can be output. -* Streams can coexist with normal value assignments. +By assigning streams like file pointers to the body of a resource, large-scale content that cannot be handled in memory can be output. Streams can also be mixed with regular variables, allowing flexible output of large responses. -### Gradual Migration from Other Systems +## Gradual Migration from Other Systems -BEAR.Sunday provides a gradual migration path, enabling seamless integration with other frameworks and systems such as Laravel and Symfony. This framework can be implemented as a Composer package, allowing developers to gradually introduce BEAR.Sunday's functionality into their existing codebase. +BEAR.Sunday provides a gradual migration path, enabling seamless integration with other frameworks and systems such as Laravel and Symfony. Since this framework can be implemented as a Composer package, developers can gradually introduce BEAR.Sunday's features into their existing codebase. -### Flexibility in Technology Migration +### Flexibility of Technology Migration -BEAR.Sunday protects investments in preparation for future technological changes and evolving requirements. Even if there is a need to migrate from this framework to another framework or language, the built resources will not be wasted. In the PHP environment, BEAR.Sunday applications can be integrated as Composer packages for continuous use, and with BEAR.Thrift, BEAR.Sunday resources can be efficiently accessed from other languages. Even without using Thrift, access via HTTP is possible. SQL code reuse is also straightforward. +BEAR.Sunday protects investments by preparing for future technological changes and evolving requirements. Even if there is a need to migrate from this framework to another framework or language, the resources built will not be wasted. In the PHP environment, BEAR.Sunday applications can be integrated as Composer packages and continuously utilized, and BEAR.Thrift allows efficient access to BEAR.Sunday resources from other languages. Even when not using Thrift, access via HTTP is possible. Reuse of SQL code is also easy. -If the dependent libraries strongly rely on a specific PHP version or library, making it difficult to upgrade to the latest PHP version, different PHP versions can coexist using BEAR.Thrift. +If the dependent libraries strongly depend on a specific PHP version or library, making it difficult to upgrade to the latest PHP version, BEAR.Thrift can be used to coexist with different PHP versions. ## Design Philosophy and Quality -### Adherence to Standards +### Adoption of Standard Technologies and Elimination of Framework-Specific Standards -* JSON format and www-form format are supported by default, and resource requests are interpreted based on the content type. -* Semantic versioning is adopted to maintain backward compatibility. -* Errors are returned in the `vnd.error+json` media type format by default, including detailed error messages. -* ETag is used to invalidate caches when the resource state changes. -* When caching, HTTP headers such as `Cache-Control`, `Age`, `Last-Modified`, and `ETag` are included in the HTTP headers. +BEAR.Sunday follows a design philosophy of adopting standard technologies wherever possible and eliminating framework-specific standards and rules. For example, it supports content negotiation for JSON format and www-form format HTTP requests by default and uses the [vnd.error+json](https://github.com/blongden/vnd.error) media type format for error responses. It actively incorporates standard technologies and specifications, such as using [HAL](https://datatracker.ietf.org/doc/html/draft-kelly-json-hal) (Hypertext Application Language) for links between resources and [JsonSchema](https://json-schema.org/) for validation. -### Object-Oriented Principles - -BEAR.Sunday emphasizes object-oriented principles to keep applications maintainable in the long run. +On the other hand, it eliminates framework-specific validation rules and standards as much as possible. -### Composition over Inheritance - -Composition is recommended over inheritance classes. In general, directly calling parent class methods from child classes can potentially increase coupling between classes. At runtime, the only abstract class that requires inheritance by design is the `BEAR\Resource\ResourceObject` class for resource classes, but its methods exist solely for the use of other classes. In BEAR.Sunday, there is no case where a user calls a method of an inherited framework parent class at runtime in any class. +### Object-Oriented Principles -### Everything is Injected +BEAR.Sunday emphasizes object-oriented principles to make applications maintainable in the long term. -Framework classes do not refer to "configuration files" or "debug constants" at runtime to determine their behavior. Dependencies with behavior corresponding to the context are injected. This means that to change the application's behavior, there is no need to change the code; only the binding of the dependency implementation to the interface needs to be changed. Constants like APP_DEBUG or APP_MODE do not exist. There is no way to know what mode the software is currently running in after it has started, nor is there a need to know. +#### Composition over Inheritance -### Non-Destructive Backward Compatibility +Composition is recommended over inheritance classes. In general, directly calling parent class methods from child classes can potentially increase coupling between classes. There is only one abstract class that requires inheritance at runtime by design, which is `BEAR\Resource\ResourceObject` in the resource class, but its methods only exist for other classes to use. There are no classes in BEAR.Sunday where the user calls methods of an inherited framework parent class at runtime. -BEAR.Sunday is designed to prioritize the maintenance of backward compatibility in software evolution. In modern software development, frequent breaking of backward compatibility and the associated burden of modifications and testing have become a challenge, but BEAR.Sunday aims to avoid this problem and has been successful. +#### Everything is Injected -This does not mean stopping the evolution of software. The Web has been changing for decades, but its core parts have remained unchanged, and backward compatibility has been maintained. BEAR.Sunday is designed to apply this spirit of the Web to application frameworks as well. +Framework classes do not refer to "configuration files" or "debug constants" at runtime to determine their behavior. Dependencies corresponding to the behavior are injected. This means that to change the application's behavior, there is no need to change the code; only the binding of the implementation of the dependency to the interface needs to be changed. There are no APP_DEBUG or APP_MODE constants. There is no way to know the current mode the software is running in after it has started, and there is no need to know. -BEAR.Sunday adopts semantic versioning to prevent new feature additions or changes to existing features from affecting existing code. Deprecated code is given the "deprecated" attribute but is never removed, and it does not affect the behavior of existing code. Instead, new features are added, and evolution continues. +### Permanent Backward Compatibility -In fact, since its release during PHP 5.4, BEAR.Sunday has had many features added, but existing applications continue to function without modification. Furthermore, with the utilization of static analysis tools that have come with the evolution of the PHP ecosystem, the code has become cleaner and faster. +BEAR.Sunday is designed with a focus on maintaining backward compatibility in the evolution of software. In modern software development, frequent breaking of backward compatibility and the associated burden of modifications and testing have become a challenge, but BEAR.Sunday aims to avoid this problem and has been successful. -This design approach, which makes backward compatibility an absolute imperative, and the semantic versioning approach make this long-term compatibility maintenance possible. This allows developers to confidently adopt BEAR.Sunday and benefit from the evolving ecosystem. +BEAR.Sunday not only adopts semantic versioning but also does not perform major version upgrades that involve breaking changes. It prevents the addition of new features or changes to existing features from impacting existing code. Deprecated code is given a "deprecated" attribute but is never removed, and it does not affect the operation of existing code. Instead, new features are added, and evolution continues. ### Code Quality -To provide high-quality applications, the BEAR.Sunday framework itself maintains a high standard of code quality. +To provide applications with high code quality, the BEAR.Sunday framework itself maintains a high standard of code quality. -* The framework code is applied with the strictest levels of both the psalm and phpstan static analysis tools. -* 100% test coverage is maintained. -* Type coverage is also nearly 100%. The use of mixed types is minimized. -* It is fundamentally an immutable system and is clean enough that reinitialization is not required for each test. It unleashes the power of PHP's asynchronous communication engines like Swoole. +* The framework code applies the most stringent levels of both psalm and phpstan static analysis tools. +* It maintains 100% test coverage, and type coverage is also nearly 100%. +* It is fundamentally an immutable system and is so clean that reinitialization is unnecessary even in tests. It brings out the power of PHP's asynchronous communication engines like Swoole. -## The Value Provided by BEAR.Sunday +## Value Brought by BEAR.Sunday ### Value for Developers -- Increased Productivity: With robust design patterns and principled constraints, developers can focus on core business logic. -- Team Collaboration: By providing consistent guidelines and structure to development teams, the code of different engineers is kept unified and loosely coupled, improving code readability and maintainability. -- Improved Maintainability: BEAR.Sunday's non-breaking backward compatibility and unchanging constraints reduce maintenance costs and enhance the long-term continuity of software. -- Flexibility and Extensibility: BEAR.Sunday's policy of not including libraries brings flexibility and freedom for developers in choosing components, allowing for adaptability to future changes. -- Ease of Testing: BEAR.Sunday's DI (Dependency Injection) and ROA (Resource-Oriented Architecture) enhance the ease of testing. +- Increased productivity: Based on robust design patterns and principles with constraints that do not change over time, developers can focus on core business logic. +- Team collaboration: By providing development teams with consistent guidelines and structure, it keeps the code of different engineers loosely coupled yet unified, improving code readability and maintainability. +- Flexibility and extensibility: BEAR.Sunday's policy of not including libraries gives developers flexibility and freedom in component selection. +- Ease of testing: BEAR.Sunday's DI (Dependency Injection) and ROA (Resource-Oriented Architecture) enhance testability. ### Value for Users -- High Performance: BEAR.Sunday's optimized fast boot and CDN (Content Delivery Network)-centric caching strategy deliver theoretically maximum performance, allowing users to enjoy fast and responsive experiences. -- Reliability and Availability: BEAR.Sunday's CDN-centric caching strategy minimizes single points of failure (SPOF) and achieves reliability and availability to the extent of continuing service delivery even if the PHP or DB server goes down. Users can enjoy stable services that do not go down. -- Ease of Use: BEAR.Sunday's excellent connectivity makes it easy to collaborate with other languages and systems. +- High performance: BEAR.Sunday's optimized fast startup and CDN (Content Delivery Network)-centric caching strategy bring users a fast and responsive experience. +- Reliability and availability: BEAR.Sunday's CDN-centric caching strategy minimizes single points of failure (SPOF), allowing users to enjoy stable services. +- Ease of use: BEAR.Sunday's excellent connectivity makes it easy to collaborate with other languages and systems. ### Value for Businesses -- Reduced Development Costs: The consistent guidelines and structure provided by BEAR.Sunday promote a sustainable and efficient development process, reducing development costs. -- Reduced Maintenance Costs: BEAR.Sunday's approach to maintaining backward compatibility enhances technical continuity, minimizing the time and cost of change management. -- High Scalability: With techniques like DI (Dependency Injection) and AOP (Aspect-Oriented Programming) that allow changing behavior while minimizing code changes, BEAR.Sunday enables applications to be easily expanded in line with business growth and changes. -- Excellent User Experience (UX): By delivering high performance and high availability, BEAR.Sunday enhances user satisfaction. Excellent UX contributes to improved customer loyalty, expansion of the customer base, and business success. +- Reduced development costs: The consistent guidelines and structure provided by BEAR.Sunday promote a sustainable and efficient development process, reducing development costs. +- Reduced maintenance costs: BEAR.Sunday's approach to maintaining backward compatibility increases technological continuity and minimizes the time and cost of change response. +- High scalability: With technologies like DI (Dependency Injection) and AOP (Aspect-Oriented Programming), BEAR.Sunday allows applications to be easily expanded in line with business growth and changes while minimizing code changes. +- Excellent User Experience (UX): By providing high performance and high availability, BEAR.Sunday enhances user satisfaction, increases customer loyalty, expands the customer base, and contributes to business success. -Great constraints do not change. The constraints brought by BEAR.Sunday provide concrete value to developers, users, and businesses alike. +Great constraints do not change. The constraints brought by BEAR.Sunday provide specific value to developers, users, and businesses respectively. -BEAR.Sunday, a framework designed based on the principles and spirit of the Web, empowers developers to build flexible and robust applications by providing them with excellent constraints. +BEAR.Sunday is a framework designed based on the principles and spirit of the Web, empowering developers to build flexible and robust applications by providing excellent constraints.