Architecture Constraints

Architecture constraints define the boundaries and non-negotiable conditions under which the BookWorm system must be designed and implemented. They ensure alignment across teams, reduce architectural drift, and make explicit the trade-offs that were accepted.

---

Technical Constraints

Constraint	Description	Rationale	Impact	Negotiable	Trade-offs
.NET Aspire	Cloud-native application framework	Simplified development, built-in observability, service discovery	Foundation for service orchestration, telemetry integration	Low	Ecosystem still evolving, fewer samples/community resources
Azure Container Apps	Primary deployment target	Managed container service with auto-scaling, serverless capabilities	Streamlined Azure-native deployments	Medium	Vendor lock-in to Azure, less portability to other clouds
Docker	Containerization platform	Consistent deployments, environment parity, isolation	Developer experience, portability	Low	Adds local complexity for onboarding and toolchain setup
PostgreSQL	Primary database system	ACID compliance, JSON support, open source, strong ecosystem	Robust persistence layer	Medium	Horizontal scaling harder than NoSQL, requires tuning for very high loads
RabbitMQ	Message broker	Reliable message delivery, mature ecosystem, clustering support	Enables event-driven architecture	Medium	Operational overhead, monitoring complexity
Azure Cloud Platform	Core cloud provider	Managed services, integration capabilities, cost optimization	Seamless integration with Aspire & Azure services	Low	Ties system to Azure cloud ecosystem

---

Development Constraints

Constraint	Description	Rationale	Impact	Negotiable	Trade-offs
Domain-Driven Design	Mandatory architectural approach	Ensures service boundaries and ubiquitous language	Influences model design and service decomposition	No	Higher learning curve, requires discipline in modeling
Vertical Slice Architecture	Required code organization pattern	Promotes modularity and feature-centric development	Simplifies testing, clearer ownership of features	No	May feel less familiar to developers used to layered architecture
Automated Testing	Unit, integration, and contract testing	Increases reliability, confidence in deployments	Ensures regressions are caught early	Low	Increases upfront development effort
CI/CD Pipelines	All services must use automated pipelines	Guarantees repeatability, quality gates, and deployment safety	Faster feedback loops, predictable releases	Medium	Pipeline maintenance overhead, longer build times
Code Quality Standards	Static analysis, style guidelines, linting	Improves maintainability and consistency across teams	Shared practices across contributors	Medium	May slow down initial development if tooling is strict

---

Security & Compliance Constraints

Constraint	Description	Rationale	Impact	Negotiable	Trade-offs
Authentication/IdP	Use OIDC/OAuth2 via Keycloak	Centralized auth, secure token-based access	Consistent identity management	Low	Adds external dependency, requires proper configuration
Secrets Management	Use Azure Key Vault	Secure secret storage, rotation policies	Reduces risk of leaks, supports auditing	No	Extra cost, requires managed service access
Encryption	TLS in transit, TDE/SSE at rest	Compliance, protects sensitive user data	Strong data protection	No	Slight performance overhead
Compliance Standards	Must align with GDPR and local laws	Regulatory requirements for personal data	Protects system from legal liabilities	Low	Extra complexity in data retention and deletion strategies

---

Observability Constraints

Constraint	Description	Rationale	Impact	Negotiable	Trade-offs
OpenTelemetry	Standardized tracing/metrics/logs	Unified observability across services	Easier debugging and performance monitoring	Low	Requires consistent implementation across all services
Distributed Tracing	Correlation IDs across services	Enables tracking of cross-service workflows	Faster incident resolution	Medium	Adds overhead to logging, requires training for interpretation
Centralized Dashboards	Azure Monitor / Grafana dashboards	Proactive monitoring and visibility	Improves reliability and reduces MTTR	Medium	Higher storage costs, risk of noise if not curated carefully

---

Summary

These architecture constraints establish the non-negotiable foundation of the system while making clear which areas are flexible. They balance innovation (e.g., Aspire, Qdrant) with proven practices (e.g., PostgreSQL, DDD), and provide guardrails for teams to build consistently and securely within agreed boundaries.