Coming in October 2026
A reference Angular 22 codebase for teams that keep re-litigating the same technical decisions. Here, it's not the code that matters most, but the decision. It comes with its context, and also with the cases where it doesn't apply.
Early access at 40% off. One email at launch, nothing else.
You're on the list. You'll hear from me once, when it ships.
src/app/features/invoicing/domain/invoice.ts:3:1 3 | import { HttpClient } from '@angular/common/http'; | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ✖ The domain layer must not know about the framework. Move this dependency to infrastructure, behind a port. boundaries/dependencies 1 problem (1 error, 0 warnings)
Every team has a wiki where coding rules get written down. Every developer is supposed to follow them, and six months later, only the person who wrote a rule still remembers it exists. Here, CI is the memory instead.
Three layers, not four. The fourth one, the application layer, only shows up when a use case touches more than one port.
Invoicing: list, detail, creation. Real business rules, real value objects, real error paths. Read it once, and you can copy it straight into your own feature.
invoicing/ ├── domain/ │ ├── invoice.ts entity + state machine │ ├── money.ts value object │ └── invoice-repository.ts port ├── application/ │ └── issue-invoice.ts two ports, so it earns a use case ├── infrastructure/ │ ├── http-invoice-repository.ts │ └── invoice.mapper.ts └── presentation/ ├── invoice-list.store.ts calls the port directly ├── invoice-form.component.ts └── invoice-form.component.spec.ts
The rule above can fail CI, but that's not the case for every decision. Signal Store instead of a service isn't something that can be checked automatically, it's a judgment call that needs a different kind of approval.
Twelve architecture decisions ship with the repo. Each one comes with its context, the decision itself, and where that decision stops applying. This is the part your team will actually argue about.
Feature state is shared across sibling components, loaded asynchronously, and derived in several places.
One NgRx Signal Store per feature, exposed read-only to components.
State that never leaves a single component (an isolated form, a toggle) does not need a store. Use a signal in the component and move on. A store here costs you a file and buys you nothing.
You're not buying code. You're buying a position you can defend in an architecture review.
And these rules aren't set in stone. Updates are included because an architecture evolves along with the project. When a decision is no longer valid, it gets revised, dated, and explained. You're buying a development philosophy that reflects current practices, not the one from two years ago.
Lifetime licence, private GitHub repository, updates included. Invoiced, so you can expense it.