Business Architecture Evaluation

This document provides a comprehensive evaluation of HotCRM's business module design from a functional perspective, identifies architectural improvements, and recommends a strategic direction for future development.

Current Architecture Overview

HotCRM delivers enterprise CRM capabilities through 6 business clouds organized as independent plugins:

Supporting packages:

• @hotcrm/core — Foundation schemas and utilities
• @hotcrm/ai — Unified AI/ML service layer
• @hotcrm/server — Application server and runtime

Design Evaluation

Strengths

1. Clean Plugin Architecture: Each business cloud is an independent plugin with explicit dependencies, enabling selective deployment.

2. Metadata-Driven Design: All objects are defined in TypeScript using the ServiceObject interface, ensuring type safety and consistency.

3. AI-Native Integration: AI capabilities are woven into business objects (lead scoring, case auto-categorization, AI recommendations) rather than bolted on as afterthoughts.

4. Comprehensive Object Model: 64+ objects covering the full customer lifecycle from lead capture to payment collection.

5. Separation of Concerns: The file suffix protocol (.object.ts, .hook.ts, .action.ts, .page.ts) enforces clear responsibility boundaries.

Issues Identified

Marketing Objects Placement

Current State: Five marketing automation objects (EmailTemplate, Form, LandingPage, MarketingList, Unsubscribe) are currently placed in the @hotcrm/crm package, while the @hotcrm/marketing package only contains Campaign and CampaignMember.

Impact:

• The CRM plugin is overloaded with 13 objects spanning two functional domains (sales + marketing automation)
• The Marketing plugin is unnaturally thin with only 2 objects
• Customers wanting CRM-only deployment are forced to include marketing automation objects

Recommendation: Consider migrating these 5 objects to @hotcrm/marketing in a future release to create a clean separation:

• CRM (8 objects): Account, Contact, Lead, Opportunity, Activity, Task, Note, AssignmentRule
• Marketing (7 objects): Campaign, CampaignMember, EmailTemplate, LandingPage, Form, MarketingList, Unsubscribe

HR Cloud Independence

The @hotcrm/hr package (16 objects) is functionally independent from core CRM. It has:

• No dependency on CRM objects (Account, Contact, Lead, Opportunity)
• Only a dependency on @hotcrm/core for shared utilities
• Its own AI agents (Recruitment Assistant, Performance Coach)

Recommendation: HR should remain as a separate plugin within the monorepo rather than being split into a separate project. Reasons:

1. Shared infrastructure (build system, testing, CI/CD) reduces maintenance overhead
2. Cross-cloud features (e.g., linking employees to accounts) are easier in a monorepo
3. The plugin architecture already enables independent deployment and licensing
4. Splitting into a separate repository would double the DevOps burden without clear benefit

HR should be licensed and priced separately from core CRM (see Editions & Pricing).

Revenue Cloud Split

The Revenue Cloud spans two packages (@hotcrm/products + @hotcrm/finance). This split is correct:

• Products handles pre-sale (catalog, pricing, quoting)
• Finance handles post-sale (contracts, invoicing, payments)
• They can be deployed independently based on customer needs

Recommended Feature Expansion

Short-Term (Phase 2)

Medium-Term (Phase 3)

Long-Term (Phase 4)

Plugin Dependency Graph

@hotcrm/core (Foundation)
    ├── @hotcrm/ai (AI Services)
    │   └── @hotcrm/core
    ├── @hotcrm/crm (Sales Cloud)
    │   ├── @hotcrm/core
    │   └── @hotcrm/ai
    ├── @hotcrm/marketing (Marketing Cloud)
    │   └── @hotcrm/crm
    ├── @hotcrm/products (Revenue Cloud - CPQ)
    ├── @hotcrm/finance (Revenue Cloud - Billing)
    ├── @hotcrm/support (Service Cloud)
    └── @hotcrm/hr (HR Cloud)
        └── @hotcrm/core

Conclusion

HotCRM's plugin-based architecture is fundamentally sound. The main recommendation is to migrate marketing automation objects from @hotcrm/crm to @hotcrm/marketing in a future release, which would strengthen the separation of concerns and enable cleaner edition-based licensing. The HR Cloud is correctly positioned as an independent plugin that can be separately licensed without requiring a project split. See Editions & Pricing for the recommended pricing strategy.