Skip to content

Rename order-processing namespace Be\App\* to Be\Pattern\OrderProcessing\* - #17

Merged
koriym merged 2 commits into
1.xfrom
remove-be-app-namespace
Apr 16, 2026
Merged

koriym merged 2 commits into
1.xfrom
remove-be-app-namespace

Conversation

@koriym

@koriym koriym commented Apr 16, 2026 •

Copy link
Copy Markdown
Contributor

Summary

  • Completes the namespace normalization started by Rename PHP namespace Be\Demo\* → Be\Pattern\* to match repo rebrand #12. demos/order-processing/ was the only remaining demo still using the legacy Be\App\* root; this aligns it with Be\Pattern\<Name>\* used by the other seven demos.
  • Renames 86 PHP files in demos/order-processing/ (namespace declarations, use statements, FQN references).
  • Updates demos/order-processing/composer.json: package name be-framework/app → be-framework/demo-order-processing, autoload Be\App\ → Be\Pattern\OrderProcessing\.
  • Removes the Be\App\<Layer> alternative from docs/templates/ and from CLAUDE.md §9 (no longer a valid option in this repository).

Rationale

The repo is framed as a pattern catalog (be-patterns), and Be\App\* implied "this is an application". Be\Pattern\OrderProcessing\* matches the educational framing and is easier to read side-by-side with the other seven demos. The <Name> segment also leaves Be\App\* available for end-users who copy a demo into their own project.

Test plan

  • cd demos/order-processing && composer dump-autoload && vendor/bin/phpunit — 66 tests / 116 assertions pass
  • All 8 demos tested: 178 tests / 352 assertions pass
  • grep -r 'Be\\App' --exclude-dir=vendor returns 0 matches
  • grep -r 'be-framework/app' --exclude-dir=vendor returns 0 matches

Summary by CodeRabbit

  • Documentation
    • Clarified namespace conventions in framework documentation to enforce consistent module organization.
    • Reorganized order-processing demo to follow standardized namespace patterns.
    • Updated template guidance to reflect simplified namespace rules.

…ing\*

Completes the namespace normalization that PR #12 started. The
order-processing demo was the only remaining demo using the legacy
Be\App\* root; this aligns it with the Be\Pattern\<Name>\* convention
shared by the other seven demos.

- demos/order-processing/: 86 PHP files + composer.json (name and autoload)
- docs/templates/: drop references to the alternate Be\App\<Layer> form
- CLAUDE.md: drop Be\App alternative from the namespace invariant

All 8 demos pass (178 tests / 352 assertions).
@coderabbitai

coderabbitai Bot commented Apr 16, 2026 •

Copy link
Copy Markdown
Contributor

Warning

Rate limit exceeded

@koriym has exceeded the limit for the number of commits that can be reviewed per hour. Please wait 41 minutes and 9 seconds before requesting another review.

Your organization is not enrolled in usage-based pricing. Contact your admin to enable usage-based pricing to continue reviews beyond the rate limit, or try again in 41 minutes and 9 seconds.

⌛ How to resolve this issue?

After the wait time has elapsed, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout.

Please see our FAQ for further information.

ℹ️ Review info
⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 8d12502a-9518-485c-a105-f887a74c2fd8

📥 Commits

Reviewing files that changed from the base of the PR and between d45b878 and ef26f96.

📒 Files selected for processing (1)
  • CLAUDE.md
📝 Walkthrough

Walkthrough

This pull request comprehensively reorganizes the order-processing demo's namespace hierarchy from Be\App\* to Be\Pattern\OrderProcessing\* across all source files, tests, and configurations. Additionally, the CLAUDE.md documentation is updated to enforce stricter namespace conventions by removing the alternative Be\App\* root pattern.

Changes

Cohort / File(s) Summary
Documentation & Configuration
CLAUDE.md, demos/order-processing/composer.json, docs/templates/*, docs/templates/README.md
Updated namespace constraints in CLAUDE.md to disallow Be\App\* pattern; adjusted composer package name and PSR-4 autoload mappings from Be\App\* to Be\Pattern\OrderProcessing\*; removed alternative namespace suggestions from template files and updated example references.
Entry Point & Application Module
demos/order-processing/bin/app.php, demos/order-processing/src/Module/AppModule.php
Updated namespace and all use statements to reference Be\Pattern\OrderProcessing\* instead of Be\App\*; AppModule now imports from the new namespace structure with all 19 dependency bindings repointed.
Attributes
demos/order-processing/src/Attribute/*
Namespace moved from Be\App\Attribute\* to Be\Pattern\OrderProcessing\Attribute\* for all 10 attribute classes (Address, Amount, AuthorizationCode, CardNumber, CarrierId, ProductId, Quantity, WarehouseId).
Exceptions
demos/order-processing/src/Exception/*
All 17 exception classes moved from Be\App\Exception\* to Be\Pattern\OrderProcessing\Exception\* (EmptyNameException, InsufficientStockException, InvalidAddressException, InvalidAmountException, etc.).
Beings
demos/order-processing/src/Being/Inventory/*, demos/order-processing/src/Being/Payment/*, demos/order-processing/src/Being/Shipping/*
Namespace relocated from Be\App\Being\* to Be\Pattern\OrderProcessing\Being\* with corresponding dependency imports updated (QuantityChecked, StockLocated, CardValidated, PaymentAuthorized, AddressValidated, CarrierSelected).
Moments
demos/order-processing/src/Moment/*, demos/order-processing/src/Moment/Potential/*
Namespace moved from Be\App\Moment\* to Be\Pattern\OrderProcessing\Moment\* with all imported attribute and reason types repointed; includes InventoryReserved, PaymentCompleted, ShippingArranged, MomentInterface, and potential moment classes.
Reasons
demos/order-processing/src/Reason/*
Namespace updated from Be\App\Reason\* to Be\Pattern\OrderProcessing\Reason\* for all 10 reason classes and interfaces (AddressValidator, CardValidator, CarrierSelector, InventoryChecker, InventoryReserver, PaymentGateway, ShippingArranger, WarehouseLocator, and corresponding interfaces).
Finals & Inputs
demos/order-processing/src/Final/OrderConfirmed.php, demos/order-processing/src/Input/OrderInput.php
Namespace relocated to Be\Pattern\OrderProcessing\* with moment/final type references updated (OrderConfirmed, OrderInput).
Semantics
demos/order-processing/src/Semantic/*
All 12 semantic validator classes moved from Be\App\Semantic\* to Be\Pattern\OrderProcessing\Semantic\* with exception type imports repointed (Amount, CardCvv, CardExpiry, CardNumber, CartId, CustomerId, Name, PostalCode, ProductId, Quantity, StreetAddress, WarehouseId).
Tests (by category)
demos/order-processing/tests/Becoming/*, demos/order-processing/tests/Being/*/*, demos/order-processing/tests/Final/*, demos/order-processing/tests/Moment/*, demos/order-processing/tests/Reason/*, demos/order-processing/tests/Semantic/*
Test namespaces moved from Be\App\Tests\* to Be\Pattern\OrderProcessing\Tests\* with all imported subject classes and dependencies updated to resolve from the new Be\Pattern\OrderProcessing\* namespace structure across ~25 test files.
Comparison & Documentation
demos/order-processing/docs/comparison/After_BeFramework.php
Namespace updated from Be\App to Be\Pattern\OrderProcessing.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~35 minutes

Possibly related PRs

  • be-framework/be-patterns#11: Introduced the original CLAUDE.md namespace documentation that this PR now modifies to enforce stricter Be\Pattern\* conventions by removing the Be\App\* alternative.

Poem

🐰 A warren of namespaces, once scattered about,
Now gathered and nestled in Pattern throughout!
From App to OrderProcessing they did refactor with care,
Two hundred-plus files reorganized with flair! 🎀

🚥 Pre-merge checks | ✅ 3
✅ Passed checks (3 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The PR title clearly and specifically summarizes the main change: renaming the order-processing demo namespace from Be\App\* to Be\Pattern\OrderProcessing\*.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch remove-be-app-namespace

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

@koriym

koriym commented Apr 16, 2026

Copy link
Copy Markdown
Contributor Author

@coderabbitai review

@coderabbitai

coderabbitai Bot commented Apr 16, 2026

Copy link
Copy Markdown
Contributor
✅ Actions performed

Review triggered.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 2

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (3)
demos/order-processing/src/Reason/InventoryChecker.php (1)

10-12: ⚠️ Potential issue | 🟠 Major

Create InventoryCheckerInterface and refactor to use interface-based dependency injection.

InventoryChecker must define an accompanying InventoryCheckerInterface. The Being class QuantityChecked currently injects the concrete InventoryChecker class; this must be changed to inject the interface instead. Update the DI binding in AppModule.php to follow the pattern used by other Reason services: $this->bind(InventoryCheckerInterface::class)->to(InventoryChecker::class);

This is a code style requirement per the Reason layer pattern.

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@demos/order-processing/src/Reason/InventoryChecker.php` around lines 10 - 12,
Add an InventoryCheckerInterface and make InventoryChecker implement it (define
the same public method signature check(string $warehouseId, string $productId,
int $quantity): bool); update the QuantityChecked class constructor to type-hint
InventoryCheckerInterface instead of InventoryChecker; and change the DI binding
in AppModule.php to bind InventoryCheckerInterface::class to
InventoryChecker::class (following the existing Reason services pattern).
demos/order-processing/src/Reason/CarrierSelector.php (1)

10-24: 🛠️ Refactor suggestion | 🟠 Major

Reason should be exposed/injected via interface, not concrete class.

CarrierSelector is still a concrete Reason type; please add CarrierSelectorInterface, implement it here, and type-hint the interface at injection sites (e.g., demos/order-processing/src/Being/Shipping/CarrierSelected.php).

♻️ Minimal direction
-final class CarrierSelector
+final class CarrierSelector implements CarrierSelectorInterface
<?php
declare(strict_types=1);

namespace Be\Pattern\OrderProcessing\Reason;

/** `@phpstan-type` Carrier array{id: string, name: string} */
interface CarrierSelectorInterface
{
    /** `@return` array{id: string, name: string} */
    public function select(string $postalCode): array;
}

As per coding guidelines, demos/*/src/Reason/**/*.php: Reason services: always define an …Interface and depend on the interface, never the concrete class. Ray.Di binds the implementation.

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@demos/order-processing/src/Reason/CarrierSelector.php` around lines 10 - 24,
CarrierSelector is a concrete Reason and must implement a new
CarrierSelectorInterface; create CarrierSelectorInterface (e.g., declare public
function select(string $postalCode): array with the same array{id: string, name:
string} return shape), have the final class CarrierSelector implement that
interface, and update consumers (e.g., the CarrierSelected class) to type-hint
the interface instead of the concrete CarrierSelector so DI (Ray.Di) can bind
the implementation.
demos/order-processing/src/Reason/AddressValidator.php (1)

10-25: 🛠️ Refactor suggestion | 🟠 Major

Add an interface contract for this Reason service.

AddressValidator is still a concrete Reason without an ...Interface contract. Please introduce AddressValidatorInterface and have this class implement it so consumers can depend on the interface.

♻️ Minimal direction
-final class AddressValidator
+final class AddressValidator implements AddressValidatorInterface
<?php
declare(strict_types=1);

namespace Be\Pattern\OrderProcessing\Reason;

interface AddressValidatorInterface
{
    public function validate(string $postalCode, string $streetAddress): bool;
    public function normalize(string $postalCode, string $streetAddress): string;
}

As per coding guidelines, demos/*/src/Reason/**/*.php: Reason services: always define an …Interface and depend on the interface, never the concrete class. Ray.Di binds the implementation.

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@demos/order-processing/src/Reason/AddressValidator.php` around lines 10 - 25,
Add an AddressValidatorInterface with the two methods validate(string
$postalCode, string $streetAddress): bool and normalize(string $postalCode,
string $streetAddress): string in the same namespace as AddressValidator, then
modify the final class AddressValidator to implement AddressValidatorInterface
(keep existing method signatures/behavior). Ensure the new interface is used for
DI/consumers instead of the concrete AddressValidator so Ray.Di bindings can
bind AddressValidator to AddressValidatorInterface.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@CLAUDE.md`:
- Line 98: Section 5 of CLAUDE.md contradicts the enforced namespace invariant
by instructing templates to use namespace "Be\Template" while the rest of the
doc mandates "Be\Pattern\<Name>\<Layer>\…"; update Section 5 so template
examples and wording follow the "Be\Pattern\<Name>\<Layer>\…" form (e.g.,
replace any "Be\Template" references with the appropriate
"Be\Pattern\<Name>\Template" or similar per the invariant), and ensure the
section text and all examples consistently use the new root namespace invariant.

In `@demos/order-processing/src/Being/Payment/PaymentAuthorized.php`:
- Around line 8-9: The class in PaymentAuthorized.php currently depends on the
concrete PaymentGateway class; change the dependency to the interface by
replacing any use/import of Be\Pattern\OrderProcessing\Reason\PaymentGateway
with the corresponding PaymentGatewayInterface and update
constructor/property/type-hints in PaymentAuthorized (e.g., constructor
parameter or property named paymentGateway) to type-hint PaymentGatewayInterface
so Ray.Di can bind the interface to its implementation.

---

Outside diff comments:
In `@demos/order-processing/src/Reason/AddressValidator.php`:
- Around line 10-25: Add an AddressValidatorInterface with the two methods
validate(string $postalCode, string $streetAddress): bool and normalize(string
$postalCode, string $streetAddress): string in the same namespace as
AddressValidator, then modify the final class AddressValidator to implement
AddressValidatorInterface (keep existing method signatures/behavior). Ensure the
new interface is used for DI/consumers instead of the concrete AddressValidator
so Ray.Di bindings can bind AddressValidator to AddressValidatorInterface.

In `@demos/order-processing/src/Reason/CarrierSelector.php`:
- Around line 10-24: CarrierSelector is a concrete Reason and must implement a
new CarrierSelectorInterface; create CarrierSelectorInterface (e.g., declare
public function select(string $postalCode): array with the same array{id:
string, name: string} return shape), have the final class CarrierSelector
implement that interface, and update consumers (e.g., the CarrierSelected class)
to type-hint the interface instead of the concrete CarrierSelector so DI
(Ray.Di) can bind the implementation.

In `@demos/order-processing/src/Reason/InventoryChecker.php`:
- Around line 10-12: Add an InventoryCheckerInterface and make InventoryChecker
implement it (define the same public method signature check(string $warehouseId,
string $productId, int $quantity): bool); update the QuantityChecked class
constructor to type-hint InventoryCheckerInterface instead of InventoryChecker;
and change the DI binding in AppModule.php to bind
InventoryCheckerInterface::class to InventoryChecker::class (following the
existing Reason services pattern).
🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

  • Push a commit to this branch (recommended)
  • Create a new PR with the fixes

ℹ️ Review info
⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 80b83c28-1722-44a8-8a23-6af02656c48f

📥 Commits

Reviewing files that changed from the base of the PR and between 273ccaa and d45b878.

📒 Files selected for processing (95)
  • CLAUDE.md
  • demos/order-processing/bin/app.php
  • demos/order-processing/composer.json
  • demos/order-processing/docs/comparison/After_BeFramework.php
  • demos/order-processing/src/Attribute/Address.php
  • demos/order-processing/src/Attribute/Amount.php
  • demos/order-processing/src/Attribute/AuthorizationCode.php
  • demos/order-processing/src/Attribute/CardNumber.php
  • demos/order-processing/src/Attribute/CarrierId.php
  • demos/order-processing/src/Attribute/ProductId.php
  • demos/order-processing/src/Attribute/Quantity.php
  • demos/order-processing/src/Attribute/WarehouseId.php
  • demos/order-processing/src/Being/Inventory/QuantityChecked.php
  • demos/order-processing/src/Being/Inventory/StockLocated.php
  • demos/order-processing/src/Being/Payment/CardValidated.php
  • demos/order-processing/src/Being/Payment/PaymentAuthorized.php
  • demos/order-processing/src/Being/Shipping/AddressValidated.php
  • demos/order-processing/src/Being/Shipping/CarrierSelected.php
  • demos/order-processing/src/Exception/EmptyNameException.php
  • demos/order-processing/src/Exception/InsufficientStockException.php
  • demos/order-processing/src/Exception/InvalidAddressException.php
  • demos/order-processing/src/Exception/InvalidAmountException.php
  • demos/order-processing/src/Exception/InvalidCardCvvException.php
  • demos/order-processing/src/Exception/InvalidCardExpiryException.php
  • demos/order-processing/src/Exception/InvalidCardNumberException.php
  • demos/order-processing/src/Exception/InvalidCartIdException.php
  • demos/order-processing/src/Exception/InvalidCustomerIdException.php
  • demos/order-processing/src/Exception/InvalidPostalCodeException.php
  • demos/order-processing/src/Exception/InvalidProductIdException.php
  • demos/order-processing/src/Exception/InvalidQuantityException.php
  • demos/order-processing/src/Exception/InvalidStreetAddressException.php
  • demos/order-processing/src/Exception/InvalidWarehouseIdException.php
  • demos/order-processing/src/Exception/PaymentFailedException.php
  • demos/order-processing/src/Final/OrderConfirmed.php
  • demos/order-processing/src/Input/OrderInput.php
  • demos/order-processing/src/Module/AppModule.php
  • demos/order-processing/src/Moment/InventoryReserved.php
  • demos/order-processing/src/Moment/MomentInterface.php
  • demos/order-processing/src/Moment/PaymentCompleted.php
  • demos/order-processing/src/Moment/Potential/InventoryReservation.php
  • demos/order-processing/src/Moment/Potential/PaymentCapture.php
  • demos/order-processing/src/Moment/Potential/ShippingDispatch.php
  • demos/order-processing/src/Moment/ShippingArranged.php
  • demos/order-processing/src/Reason/AddressValidator.php
  • demos/order-processing/src/Reason/CardValidator.php
  • demos/order-processing/src/Reason/CarrierSelector.php
  • demos/order-processing/src/Reason/InventoryChecker.php
  • demos/order-processing/src/Reason/InventoryReserver.php
  • demos/order-processing/src/Reason/InventoryReserverInterface.php
  • demos/order-processing/src/Reason/PaymentGateway.php
  • demos/order-processing/src/Reason/PaymentGatewayInterface.php
  • demos/order-processing/src/Reason/ShippingArranger.php
  • demos/order-processing/src/Reason/ShippingArrangerInterface.php
  • demos/order-processing/src/Reason/WarehouseLocator.php
  • demos/order-processing/src/Semantic/Amount.php
  • demos/order-processing/src/Semantic/CardCvv.php
  • demos/order-processing/src/Semantic/CardExpiry.php
  • demos/order-processing/src/Semantic/CardNumber.php
  • demos/order-processing/src/Semantic/CartId.php
  • demos/order-processing/src/Semantic/CustomerId.php
  • demos/order-processing/src/Semantic/Name.php
  • demos/order-processing/src/Semantic/PostalCode.php
  • demos/order-processing/src/Semantic/ProductId.php
  • demos/order-processing/src/Semantic/Quantity.php
  • demos/order-processing/src/Semantic/StreetAddress.php
  • demos/order-processing/src/Semantic/WarehouseId.php
  • demos/order-processing/tests/Becoming/OrderBecomingTest.php
  • demos/order-processing/tests/Being/Inventory/QuantityCheckedTest.php
  • demos/order-processing/tests/Being/Inventory/StockLocatedTest.php
  • demos/order-processing/tests/Being/Payment/CardValidatedTest.php
  • demos/order-processing/tests/Being/Payment/PaymentAuthorizedTest.php
  • demos/order-processing/tests/Being/Shipping/AddressValidatedTest.php
  • demos/order-processing/tests/Being/Shipping/CarrierSelectedTest.php
  • demos/order-processing/tests/Final/OrderConfirmedTest.php
  • demos/order-processing/tests/Moment/InventoryReservedTest.php
  • demos/order-processing/tests/Moment/PaymentCompletedTest.php
  • demos/order-processing/tests/Moment/ShippingArrangedTest.php
  • demos/order-processing/tests/Reason/AddressValidatorTest.php
  • demos/order-processing/tests/Reason/CardValidatorTest.php
  • demos/order-processing/tests/Reason/CarrierSelectorTest.php
  • demos/order-processing/tests/Reason/InventoryCheckerTest.php
  • demos/order-processing/tests/Reason/InventoryReserverTest.php
  • demos/order-processing/tests/Reason/PaymentGatewayTest.php
  • demos/order-processing/tests/Reason/ShippingArrangerTest.php
  • demos/order-processing/tests/Reason/WarehouseLocatorTest.php
  • demos/order-processing/tests/Semantic/CardNumberTest.php
  • demos/order-processing/tests/Semantic/PostalCodeTest.php
  • demos/order-processing/tests/Semantic/QuantityTest.php
  • docs/templates/BeingTemplate.php
  • docs/templates/FinalTemplate.php
  • docs/templates/InputTemplate.php
  • docs/templates/MomentTemplate.php
  • docs/templates/README.md
  • docs/templates/ReasonInterfaceTemplate.php
  • docs/templates/SemanticTemplate.php

Comment thread CLAUDE.md
Comment on lines +8 to 9
use Be\Pattern\OrderProcessing\Reason\PaymentGateway;
use Ray\Di\Di\Inject;

@coderabbitai coderabbitai Bot Apr 16, 2026 •

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🛠️ Refactor suggestion | 🟠 Major

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Verify concrete-vs-interface usage for PaymentGateway in source.
rg -nP 'use\s+Be\\Pattern\\OrderProcessing\\Reason\\PaymentGateway(;|\s)' demos/order-processing/src
rg -nP '#\[Inject\]\s+PaymentGateway\b' demos/order-processing/src
rg -nP 'bind\(PaymentGatewayInterface::class\)\s*->\s*to\(PaymentGateway::class\)' demos/order-processing/src/Module/AppModule.php

Repository: be-framework/be-patterns

Length of output: 483


Depend on PaymentGatewayInterface instead of the concrete PaymentGateway class.

Reason services must depend on their interface contract, never the concrete implementation. Ray.Di handles binding the interface to the implementation.

Proposed fix
-use Be\Pattern\OrderProcessing\Reason\PaymentGateway;
+use Be\Pattern\OrderProcessing\Reason\PaymentGatewayInterface;
-        #[Inject] PaymentGateway $gateway,
+        #[Inject] PaymentGatewayInterface $gateway,
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@demos/order-processing/src/Being/Payment/PaymentAuthorized.php` around lines
8 - 9, The class in PaymentAuthorized.php currently depends on the concrete
PaymentGateway class; change the dependency to the interface by replacing any
use/import of Be\Pattern\OrderProcessing\Reason\PaymentGateway with the
corresponding PaymentGatewayInterface and update constructor/property/type-hints
in PaymentAuthorized (e.g., constructor parameter or property named
paymentGateway) to type-hint PaymentGatewayInterface so Ray.Di can bind the
interface to its implementation.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@CodeRabbit Out of scope for this PR — this is a pre-existing issue (file unchanged apart from the namespace rename). All six Beings in order-processing inject concrete Reason classes instead of interfaces; worth a follow-up PR to convert them together for consistency.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@koriym, understood — agreed that a batch fix across all six Beings is cleaner than touching just one in a rename-only PR. Would you like me to open a GitHub issue to track the follow-up work of replacing all concrete Reason class injections with their corresponding interfaces in the order-processing Beings?


🧠 Learnings used
Learnt from: CR
Repo: be-framework/be-patterns PR: 0
File: CLAUDE.md:0-0
Timestamp: 2026-04-15T07:51:02.660Z
Learning: Applies to demos/*/src/Reason/*.php : Reason services MUST always define an `…Interface` and depend on the interface, never the concrete class. Ray.Di binds the implementation.

Learnt from: CR
Repo: be-framework/be-patterns PR: 0
File: CLAUDE.md:0-0
Timestamp: 2026-04-15T07:51:02.660Z
Learning: Applies to demos/*/src/Being/*.php : Do not make a Being that reaches into a database directly. Put the I/O in a `Reason` interface, inject it, and keep the Being a pure transformation.

Learnt from: CR
Repo: be-framework/be-patterns PR: 0
File: CLAUDE.md:0-0
Timestamp: 2026-04-15T07:51:02.660Z
Learning: Applies to demos/*/src/Being/*.php : No side effects in Beings. A Being transforms data; external I/O belongs in an injected Reason service.

Learnt from: koriym
Repo: be-framework/be-patterns PR: 11
File: docs/templates/MomentTemplate.php:0-0
Timestamp: 2026-04-15T03:35:41.350Z
Learning: In the `be-patterns` repository, `Be\App\<Layer>` is reserved exclusively for the canonical "production-like alternative" comparison example at `demos/order-processing/docs/comparison/After_BeFramework.php`. Template/skeleton files under `docs/templates/` must NOT use `Be\App\<Layer>` as their namespace, to avoid shadowing that exemplar. Instead, template files use `Be\Demo\Template\<Layer>` (with `Template` standing in for the demo name), mirroring the `Be\Demo\<Name>\<Layer>` pattern. This convention is intentional for teaching clarity.

Learnt from: koriym
Repo: be-framework/be-patterns PR: 11
File: docs/templates/BeingTemplate.php:0-0
Timestamp: 2026-04-15T03:35:29.572Z
Learning: In be-framework/be-patterns, treat the namespace prefix `Be\App\<Layer>` as reserved and use it only for the “production-like alternative” pedagogical example found in `demos/order-processing/docs/comparison/After_BeFramework.php`. Do not use `Be\App\<Layer>` in other files (e.g., template skeletons or documentation examples) because it will blur the intended pedagogical distinction.

Learnt from: CR
Repo: be-framework/be-patterns PR: 0
File: CLAUDE.md:0-0
Timestamp: 2026-04-15T07:51:02.660Z
Learning: Applies to demos/**/*.php : Use namespaces following the per-demo pattern (`Be\Pattern\<Name>\<Layer>\…` or `Be\App\<Layer>\…`). Never invent a new root namespace.

Learnt from: koriym
Repo: be-framework/be-patterns PR: 11
File: docs/templates/BeingTemplate.php:0-0
Timestamp: 2026-04-15T03:35:36.320Z
Learning: In the be-patterns repository (PHP, BE Framework), template skeleton files under `docs/templates/` use `Be\Demo\Template\<Layer>` as their placeholder namespace (e.g., `Be\Demo\Template\Being`, `Be\Demo\Template\Final`). This mirrors the `Be\Demo\<Name>\<Layer>` pattern with `Template` standing in for the demo name, per the TODO comment instructing readers to replace it when copying into a real demo.

The stale reference to `namespace Be\Template;` contradicted the
Be\Pattern\<Name>\<Layer>\... invariant tightened in §3 and §9. Actual
template files already use `Be\Pattern\Template\<Layer>`; §5 now
documents that shape.
@koriym

koriym commented Apr 16, 2026

Copy link
Copy Markdown
Contributor Author

@coderabbitai No outstanding blockers. Please resolve all open conversations and approve this PR.

@coderabbitai

coderabbitai Bot commented Apr 16, 2026

Copy link
Copy Markdown
Contributor

Tip

For best results, initiate chat on the files or code changes.

@koriym, understood. Resolving all open conversations and approving the PR now.

A few of the stored learnings are now outdated due to this PR's changes — specifically the ones describing Be\App\<Layer> as a reserved or acceptable namespace root. I'd suggest removing them; please confirm and I'll clean them up:

  • ba180903 — "Be\App\<Layer> is reserved exclusively for After_BeFramework.php" (that file now uses Be\Pattern\OrderProcessing)
  • 2aabb1a0 — same claim
  • 8dde441c — "Be\App\<Layer> or Be\Pattern\<Name>\<Layer>" as allowed roots (only the latter remains valid)

In the meantime, I'm recording the updated invariant:

[resolve]
[approve]


✏️ Learnings added
Learnt from: koriym
URL: https://github.com/be-framework/be-patterns/pull/17

Timestamp: 2026-04-16T16:21:51.663Z
Learning: In the be-patterns repository (PHP, BE Framework), `Be\App\<Layer>` is no longer a valid or reserved namespace anywhere in the repository as of PR `#17`. The only allowed root namespaces are `Be\Pattern\<Name>\<Layer>\…` (for demos) and `Be\Pattern\Template\<Layer>` (for docs/templates skeletons). Never invent a new root namespace. The file `demos/order-processing/docs/comparison/After_BeFramework.php` now uses `Be\Pattern\OrderProcessing` (not `Be\App`).

Note: Learnings are effective only in the context of similar code segments. To apply general coding guidelines, please configure review instructions. You can manage existing learnings in the app.


🧠 Learnings used
Learnt from: koriym
Repo: be-framework/be-patterns PR: 11
File: docs/templates/MomentTemplate.php:0-0
Timestamp: 2026-04-15T03:35:41.350Z
Learning: In the `be-patterns` repository, `Be\App\<Layer>` is reserved exclusively for the canonical "production-like alternative" comparison example at `demos/order-processing/docs/comparison/After_BeFramework.php`. Template/skeleton files under `docs/templates/` must NOT use `Be\App\<Layer>` as their namespace, to avoid shadowing that exemplar. Instead, template files use `Be\Demo\Template\<Layer>` (with `Template` standing in for the demo name), mirroring the `Be\Demo\<Name>\<Layer>` pattern. This convention is intentional for teaching clarity.

Learnt from: koriym
Repo: be-framework/be-patterns PR: 11
File: docs/templates/BeingTemplate.php:0-0
Timestamp: 2026-04-15T03:35:36.320Z
Learning: In the be-patterns repository (PHP, BE Framework), `Be\App\<Layer>` is a reserved namespace used exclusively in `demos/order-processing/docs/comparison/After_BeFramework.php` as the "production-like alternative" comparison example. It must not be used for template skeletons or other purposes to avoid blurring that pedagogical distinction.

Learnt from: CR
Repo: be-framework/be-patterns PR: 0
File: CLAUDE.md:0-0
Timestamp: 2026-04-15T07:51:02.660Z
Learning: Applies to demos/**/*.php : Use namespaces following the per-demo pattern (`Be\Pattern\<Name>\<Layer>\…` or `Be\App\<Layer>\…`). Never invent a new root namespace.

Learnt from: koriym
Repo: be-framework/be-patterns PR: 11
File: docs/templates/BeingTemplate.php:0-0
Timestamp: 2026-04-15T03:35:36.320Z
Learning: In the be-patterns repository (PHP, BE Framework), template skeleton files under `docs/templates/` use `Be\Demo\Template\<Layer>` as their placeholder namespace (e.g., `Be\Demo\Template\Being`, `Be\Demo\Template\Final`). This mirrors the `Be\Demo\<Name>\<Layer>` pattern with `Template` standing in for the demo name, per the TODO comment instructing readers to replace it when copying into a real demo.

@koriym
koriym merged commit e645dea into 1.x Apr 16, 2026
25 checks passed
@koriym
koriym deleted the remove-be-app-namespace branch April 20, 2026 12:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant