Benny JooandDevin AI
ab21c7f805
* feat: Cal.diy — community-driven MIT-licensed fork of Cal.com This squashed commit contains all Cal.diy changes applied on top of calcom/cal.com main: - Rebrand Cal.com to Cal.diy across the entire codebase - Remove Enterprise Edition (EE) features, license checks, and AGPL restrictions - Switch license from AGPL-3.0 to MIT - Remove docs/ directory (migrated to Nextra at cal.diy) - Remove dead code: org tests, EE tips, platform nav, premium username, SAML/SSO, etc. - Clean up .env.example for self-hosted Cal.diy - Update Docker image references to calcom/cal.diy - Update README, CONTRIBUTING.md, and issue templates for Cal.diy community fork - Add PR welcome bot for Cal.diy contributors - Fix API v2 breaking changes oasdiff ignore entries - Replace Blacksmith CI runners with default GitHub Actions 3893 files changed, 20789 insertions(+), 411020 deletions(-) Co-Authored-By: benny@cal.com <sldisek783@gmail.com> * refactor: remove org-specific /organizations/:orgId endpoints from API v2 atoms controllers (#1701) Co-authored-by: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com> * fix: revert Cal.diy Inc to Cal.com, Inc. in license files, copyright notices, and package metadata (#1702) Co-authored-by: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com> * rip out org related comments in api v2 --------- Co-authored-by: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com>
1.9 KiB
1.9 KiB
title, impact, impactDescription, tags
| title | impact | impactDescription | tags |
|---|---|---|---|
| Enforce Feature Boundaries Through Public APIs | CRITICAL | Prevents architectural erosion and maintains loose coupling | 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):
// 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):
// 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.diy Engineering Blog