feat: add architecture style presets (Hexagonal, Clean Architecture, MVC/MVT)

[DaisukeYoda]

Summary

Introduce architecture style presets that automatically apply the correct dependency rules for specific architectural patterns (Hexagonal, Clean Architecture, MVC/MVT).

Background

The current architecture.rules provides generic allow/deny rules between layers, but does not offer optimized rule sets for specific architecture styles.

Current Problem

In default_config.toml, domain → infrastructure is allowed:

[[architecture.rules]]
from = "domain"
allow = ["domain", "infrastructure"]  # ← Violates Hexagonal/Clean Architecture
deny = ["presentation", "application"]

This violates the Dependency Inversion Principle central to Hexagonal and Clean Architecture. Users must manually configure style-specific rules, which is error-prone.

Proposal

1. Architecture Style Configuration

Users specify a style in pyscn.toml to auto-apply the appropriate rule set:

[architecture]
style = "hexagonal"  # "hexagonal" | "clean" | "mvc" | "layered" (default)

2. Preset Rules per Style

Hexagonal / Onion Architecture

• Principle: Domain layer must not depend on infrastructure (Dependency Inversion)
• Ports (interfaces) are defined in the domain layer; Adapters are implemented in infrastructure

domain → domain only (no external dependencies)
application → application, domain
infrastructure → infrastructure, domain, application
presentation → presentation, application, domain

Additional layers:

• port (ports, interfaces, contracts) → placed in the domain side
• adapter (adapters, implementations) → placed in the infrastructure side

Clean Architecture

• Principle: Inner layers must not know about outer layers
• Dependencies always flow from outside inward

entities (domain) → entities only
use_cases (application) → use_cases, entities
interface_adapters (infrastructure) → interface_adapters, use_cases, entities
frameworks (presentation) → all layers

MVC / MVT

• Principle: View → Model direct dependency is forbidden (must go through Controller/Template)

model → model only
view/template → view/template, model  (direct dependency emits warning)
controller → controller, model, view/template

3. Implementation Approach

Existing infrastructure can be leveraged directly:

Existing Component	How It's Used
ArchitectureRules in domain/system_analysis.go	Add a Style string field
internal/config/default_config.toml	Add preset definitions per style
evaluateLayerRules in service/system_analysis_service.go	Rule evaluation logic works as-is
buildModuleLayerMap pattern matching	Layer assignment works as-is

Key Changes

1. domain/system_analysis.go: Add Style field to ArchitectureRules
2. internal/config/: Add preset rule definitions (e.g., architecture_presets.go)
3. service/system_analysis_service.go: Apply preset rules when style is specified in autoDetectArchitecture
4. internal/config/config.go: Parse the style field from TOML

Auto-Detection (Future Enhancement)

Infer the architecture style from directory structure and package naming conventions:

• Presence of ports/, adapters/ → Hexagonal
• Presence of entities/, use_cases/, interface_adapters/ → Clean Architecture
• Presence of models/, views/, controllers/ → MVC

Impact

• The existing layered style (current default) maintains full backward compatibility
• When style is not specified, behavior is identical to current
• Explicit rules definitions take precedence over presets

References

• Robert C. Martin, "Clean Architecture"
• Alistair Cockburn, "Hexagonal Architecture"
• [FEATURE] Implement Architecture Metrics (Abstractness vs. Instability) #166 (Abstractness vs. Instability metrics — related feature)