software-design-principleslisted

# software-design-principles The code-level engineering canon. Markdown only, no scripts – consulted, not invoked. Workflow skills cite it; agents and humans read it. Larger scopes live in the sibling skills `architectural-design-principles` (system-level) and `ui-ux-design-principles` (experience-level). ## Architectural concerns mapping (mandatory before promote/merge) Fill this in for any non-trivial change before calling the design done. An unfilled row, or a concern with no clear owner, is a design smell – resolve it before merging. | Concern | Layer | Owner module | Cross-cutting? | |---|---|---|---| | Authentication | HTTP / boundary | `<module>` | Yes | | Authorization | Service | `<module>` | Yes | | Capability resolution | Service | `<module>` | Yes | | Audit logging | Cross-cutting | `<module>` | Yes | | Rate limiting | HTTP / boundary | `<module>` | Yes | | Schema validation | HTTP / boundary | `<module>` | Yes | | Policy config | Service / config | `<module>` | Yes | | Domain logic | Service | `<module>` | No | | Storage | Infrastructure | `<module>` | No | ## References - [SOLID](references/solid.md) – the five object-design rules. - [DRY](references/dry.md) – one home for each piece of logic. - [Clean code](references/clean-code.md) – naming, function shape, comments, error boundaries. - [Cross-cutting concerns](references/cross-cutting-concerns.md) – which layer owns auth, authz, capability resolution, audit, rate limiting, schema, policy. - [NFRs](refer