Nm Archetypes Architecture Paradigm Layered

Layered (n-tier) architecture with enforced layer boundaries and separation of concerns

Security Scan

This is a documentation-only skill that provides guidance on layered (n‑tier) architecture and does not request credentials, install software, or instruct the agent to access unrelated system resources.

Purpose & Capability

The name/description (layered architecture / separation of concerns) matches the SKILL.md content. There are no unexpected environment variables, binaries, or config paths declared that would be unrelated to an architecture guidance document.

Instruction Scope

The instructions are high-level architectural guidance (adoption steps, deliverables, tooling suggestions). They do not direct the agent to read files, export secrets, contact external endpoints, or run specific commands beyond generic troubleshooting advice like 'ensure dependencies are installed.'

Install Mechanism

No install spec and no code files are present; this is instruction-only, so nothing is downloaded or written to disk by the skill itself.

Credentials

The skill declares no required environment variables, credentials, or config paths. There is no disproportionate request for secrets or unrelated service tokens.

Persistence & Privilege

The skill is not always-enabled and does not request elevated persistence. It is user-invocable and can be run by agents per platform defaults, which is appropriate for a documentation-style skill.

Assessment

This skill is basically a reference document about layered architecture and appears safe to install. Keep in mind: if you later install the complementary 'Claude Code' plugin or other agent integrations mentioned in the doc, those plugins may enable code execution or automated enforcement (verify their permissions before installing). Also, when you implement the suggested automated architecture checks (ArchUnit, dep-cruise, custom scripts), review those tools and CI jobs to ensure they don't inadvertently run with excessive privileges or expose secrets.

Night Market Skill — ported from claude-night-market/archetypes. For the full experience with agents, hooks, and commands, install the Claude Code plugin.

Table of Contents

• When to Employ This Paradigm
• When NOT to Use This Paradigm
• Adoption Steps
• Key Deliverables
• Technology Guidance
• Risks & Mitigations
• Troubleshooting

The Layered (N-Tier) Architecture Paradigm

When to Employ This Paradigm

• When teams need clear architectural boundaries and a familiar structure for moderate-sized systems.
• When compliance or operations teams require clear separation of concerns (e.g., UI vs. domain logic vs. persistence).
• When the deployment artifact remains a monolith, but code clarity and separation are degrading.

When NOT To Use This Paradigm

• When high scalability demands require independent scaling of components
• When multiple teams need independent deployment cycles
• When complex business logic requires frequent cross-layer communication
• When microservices architecture is already planned or in place
• When real-time processing requirements make layered communication too slow

Adoption Steps

1. Define the Layers: Establish a clear set of layers. A common stack includes: Presentation -> Application/Service -> Domain -> Data Access.
2. Enforce Dependency Direction: Code in a given layer may only depend on the layer immediately below it. Forbid any "upward" dependencies or imports.
3. Centralize Cross-Cutting Concerns: Implement concerns like logging, authentication, and validation as centralized middleware or policies, rather than duplicating this logic in each layer.
4. Test Each Layer Appropriately: Apply testing strategies suitable for each layer, such as unit tests for the domain layer, service-layer tests for orchestration logic, and integration tests for persistence adapters.
5. Document and Enforce Interactions: Maintain up-to-date dependency diagrams and use automated architecture tests to prevent developers from creating "shortcut" dependencies that violate the layering rules.

Key Deliverables

• An Architecture Decision Record (ADR) that captures the responsibilities of each layer, the allowed dependencies between them, and the policy for any exceptions.
• A formal dependency diagram stored with the project documentation.
• Automated architectural checks (e.g., using ArchUnit, dep-cruise, or custom scripts) to prevent rule violations from being merged.

Technology Guidance

Layer Implementation Patterns:

• Presentation Layer: React/Vue/Angular (Frontend), MVC Controllers (Backend)
• Application Layer: Service classes, Application services, Use case orchestrators
• Domain Layer: Business entities, Domain services, Business rules validation
• Data Access Layer: Repository pattern, ORM mappers, Data access objects (DAO)

Architecture Enforcement Tools:

• Java: ArchUnit for dependency rule testing
• JavaScript/TypeScript: ESLint rules with dependency tracking
• C#: NDepend for architectural analysis
• Python: Custom decorators and import analysis tools

Common Layer Stacks:

• 3-Layer: Presentation → Business Logic → Data Access
• 4-Layer: Presentation → Application → Domain → Infrastructure
• 5-Layer: UI → Controller → Service → Domain → Persistence

Real-World Examples

Enterprise ERP Systems: SAP and Oracle ERP use layered architecture to separate user interfaces from business logic and database operations, enabling different frontend applications to share the same business rules.

Banking Applications: Financial institutions employ layered architecture to maintain strict separation between customer-facing interfaces, transaction processing, and secure data storage for regulatory compliance.

E-commerce Platforms: Traditional e-commerce sites use layered architecture to separate product catalogs, shopping cart logic, order processing, and payment handling into distinct layers.

Risks & Mitigations

• Excessive Rigidity and Latency:
  • Mitigation: For features that span multiple layers, strict adherence can lead to excessive "pass-through" code and increased latency. In such cases, consider using a Façade pattern to provide a more direct interface where appropriate.
• "Leaky" Layers:
  • Mitigation: Developers may be tempted to bypass architectural rules for expediency, which degrades the architecture. Treat all architectural violations as build-breaking failures or critical issues in code review.

Troubleshooting

Common Issues

Command not found Ensure all dependencies are installed and in PATH

Permission errors Check file permissions and run with appropriate privileges

Unexpected behavior Enable verbose logging with --verbose flag