Keith WilliamsandDevin AI
d4ea931bf8
* feat(agents): add modular engineering rules from 2026 standards Add a rules directory with individual rule files derived from the Cal.com Engineering in 2026 and Beyond blog post. Rules are organized by section (architecture, quality, data, api, performance, testing, patterns, culture) following the Vercel agent-skills structure. Includes: - _sections.md defining rule categories and impact levels - _template.md for creating new rules - 14 individual rule files covering key engineering standards - README documenting the rules structure and usage Co-Authored-By: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com> * feat(agents): consolidate DI and Repository+DTO docs into rules - Move di-pattern.md content to rules/patterns-di-pattern.md - Extract Repository + DTO section from knowledge-base.md into: - rules/data-repository-methods.md (method naming conventions) - rules/data-dto-boundaries.md (DTO location and naming) - Update knowledge-base.md to reference the new rule files - Delete old di-pattern.md file Co-Authored-By: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com> * chore(agents): remove stub reference sections from knowledge-base.md The rules directory is self-contained with its own README, so these redirect sections are unnecessary clutter. Co-Authored-By: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com> * refactor(agents): combine DI pattern rules into single file Merged patterns-di-pattern.md into patterns-dependency-injection.md to eliminate overlap and create one comprehensive DI guide. Co-Authored-By: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com> --------- Co-authored-by: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com>
43 lines
1.9 KiB
Markdown
43 lines
1.9 KiB
Markdown
---
|
|
title: Enforce Feature Boundaries Through Public APIs
|
|
impact: CRITICAL
|
|
impactDescription: Prevents architectural erosion and maintains loose coupling
|
|
tags: architecture, boundaries, imports, coupling
|
|
---
|
|
|
|
## Enforce Feature Boundaries Through Public APIs
|
|
|
|
**Impact: CRITICAL**
|
|
|
|
Features communicate through well-defined interfaces. If bookings needs availability data, it imports from `@calcom/features/availability` through exported interfaces, not by reaching into internal implementation details.
|
|
|
|
**Incorrect (reaching into internals):**
|
|
|
|
```typescript
|
|
// Bad - Importing internal implementation details
|
|
import { calculateSlots } from "@calcom/features/availability/services/internal/slotCalculator";
|
|
import { AvailabilityCache } from "@calcom/features/availability/lib/cache";
|
|
```
|
|
|
|
**Correct (using public API):**
|
|
|
|
```typescript
|
|
// Good - Import through the feature's public API
|
|
import { getAvailability } from "@calcom/features/availability";
|
|
import type { AvailabilityResult } from "@calcom/features/availability";
|
|
```
|
|
|
|
**Shared code placement:**
|
|
- Domain-agnostic utilities and cross-cutting concerns (auth, logging): `packages/lib`
|
|
- Shared UI primitives: `packages/ui`
|
|
|
|
**Enforcement:**
|
|
Domain boundaries are enforced automatically through linting. If `packages/features/bookings` tries to import from `packages/features/availability/services/internal`, the linter will block it. All cross-feature dependencies must go through the feature's public API.
|
|
|
|
**Benefits:**
|
|
- Discoverability: Looking for booking logic? It's all in `packages/features/bookings`
|
|
- Easier testing: Test the entire feature as a unit with all pieces in one place
|
|
- Clearer dependencies: When you see `import { getAvailability } from '@calcom/features/availability'`, you know exactly which feature you're depending on
|
|
|
|
Reference: [Cal.com Engineering Blog](https://cal.com/blog/engineering-in-2026-and-beyond)
|