Domenii — harta bounded contexts

ASYDATA e structurat după Clean Architecture: fiecare bounded context are un folder cu același nume în fiecare strat — Asy.Domain/<Context>/ (entități + reguli), Asy.Application/<Context>/ (interfețe de serviciu + DTO-uri) și Asy.Infrastructure/<Context>/ (implementări, integrări, EF Core). O parte din business-uri sunt împachetate suplimentar ca module Odoo-style sub src/Modules/Asy.Modules.*, descoperite la startup prin assembly scan. Pentru structura de straturi și modularitate vezi Clean Architecture.

Pagina asta e harta: ce face fiecare domeniu, ce entitate/serviciu îl conduce și unde se găsește în cod. Numele de pe board-ul vizual corespund grupelor de mai jos — ASYDATA pe Figma.

Cum se citește harta

Entitatea principală e aggregate root-ul din src/Asy.Domain/<Context>/.
Serviciul principal e interfața din src/Asy.Application/<Context>/Services/, implementată în src/Asy.Infrastructure/<Context>/.
Domeniile marcate 🧩 modul au și un .csproj separat în src/Modules/Asy.Modules.<Nume>/ care implementează Asy.Platform.Modules.IAsyModule (gate per-tenant prin RequireModule(...)).
Câteva domenii există doar la nivel Application (fără strat Domain propriu) — marcate explicit.

Vânzări / CRM

Achiziția unui client: de la lead până la contract semnat. Vezi fluxul în Achiziție client.

Domeniu	Ce face	Entitate	Serviciu
Companies 🧩	Entități juridice (firme, clienți, self-managed) cu multi-tenancy, roluri, TVA, statut IT-Park	`Company`	`ICompaniesService`
Contacts 🧩	Persoane fizice (admin, owner, contabil, persoană de contact) legate de companii	`Contact`	`IContactsService`
Clients 🧩	Gestiunea clienților firmei (doar la nivel Application — fără entitate de domeniu proprie)	—	—
Crm	Pipeline de vânzări + oportunități (deal-uri) cu etape, probabilitate, MRR	`CrmOpportunity`	`ICrmService`
Offers	Oferte / propuneri comerciale (Draft→Sent→Accepted/Rejected), convertibile în contract	`Offer`	`IOffersService`
Contracts	Contracte de servicii (intrare/ieșire) cu linii recurente; bază pentru generarea facturilor	`Contract`	`IContractsService`
Partners	Registru master de entități juridice (cheie IDNO), partajat între firme; ține starea sync SFS	`PartnerMaster`	`IPartnersService`

Operațional

Operarea zilnică: import e-Factură, facturare, contabilitate, task-uri. Vezi Operare zilnică.

Domeniu	Ce face	Entitate	Serviciu
Efactura 🧩	Config integrare SPV/SFS per companie (credențiale SFS criptate, stare sync, mediu)	`EfacturaIntegration`	`IEfacturaService`
Invoicing	Facturi (emise/primite) unificate într-un aggregate prin `Direction`; leagă e-Factură, MSign, contabilitate, aprobare internă	`Invoice`	`IInvoicesService`, `IInvoiceEFacturaService`
Accounting	Plan de conturi (din 1C) + reguli de postare pentru înregistrările contabile	`ChartOfAccountEntry`	`IChartOfAccountsService`
Banking 🧩	Conturi bancare ale companiilor (IBAN, valută) cu mapare la cod contabil	`BankAccount`	`IBankAccountsService`
Tasks 🧩	Task-uri de proiect (To-do/Doing/PendingReview/Done) cu assignees, milestones, dependențe, time-entry, reguli recurente	`TaskItem`	`ITasksService` (+ sub-servicii: Projects, Milestones, Followers…)
Operations	Log unificat de operațiuni 1C (postări GL) + interacțiuni umane (apeluri, email, task-uri)	`OperationLog`	(DTO-uri + entitate de domeniu)
Numbering	Contoare secvențiale per `(firm, tip)` pentru serii de documente	`DocumentCounter`	`INumberingService`
Reminders	Reminder-e one-shot pentru scadențele contractelor recurente; urmărește confirmarea/plata	`PaymentReminder`	`IPaymentRemindersService`
Reference	Date de referință statice: cursuri valutare (BNM), cote TVA — indexate pe dată	`CurrencyRate`	`IReferenceService`

Comunicare & semnare

Cum ajung documentele la oameni și cum se semnează. Vezi Comunicare și semnare și paginile de integrări de mai jos.

Domeniu	Ce face	Entitate	Serviciu	Integrare
Telegram 🧩 (worker)	Bot multi-tenant: leagă chat↔firmă, trimite carduri interactive de e-Factură, flux de aprobare permisiuni	`TelegramChat`, `TelegramCardMessage`	`ITelegramService`	Telegram
Msign 🧩	Cereri de semnătură electronică (PDF/XML) prin MSign (integrator Prasada); ține certificatul semnatarului, statusul	`MsignRequest`	`IMsignService`	MSign
Notifications	Notificări in-app (bell + drawer) + web push, din evenimente de domeniu	`Notification`, `PushSubscription`	`INotificationService`, `IWebPushSender`	Notificări
Sharing	Token-uri publice de partajare: acces read-only la documente + semnare fără cont; universal (contracte/facturi/oferte)	`DocumentShare`	`IDocumentShareService`	—
DocumentTemplates	Template-uri Google Docs pentru generare PDF (contracte, facturi, HR) cu placeholder-e	`DocumentTemplate`	`IDocumentTemplateService`	—

Domeniul Telegram marcat „🧩 (worker)” trăiește în mare parte într-un worker separat — src/Workers/Asy.Workers.Telegram/ — care consumă topicul Kafka firm.events. Vezi Flux event-driven.

Monetizare / Billing

Cum se facturează și încasează serviciul de contabilitate. Vezi Monetizare.

Domeniu	Ce face	Entitate	Serviciu
Billing	Conturi de plată / proforme (avans-facturi) emise înainte de factura fiscală	`PaymentRequest`	`IBillingServices`
Payments	Înregistrarea plăților (doar la nivel Application — fără entitate de domeniu proprie)	—	—

Platformă

Infrastructura transversală pe care stau toate domeniile de business. Vezi Context de sistem și Stack.

Domeniu	Ce face	Entitate	Serviciu
Users	Persoane autentificate (Google OAuth); identitate + profil	`User`	`IUsersService`
Tenants	Istoric de atribuiri firmă↔client (cine deservește pe cine, intervale de date)	`FirmAssignment`	(directory DB, nivel Infrastructure)
Catalog	Nomenclator master de bunuri/servicii/lucrări cu SKU, unitate, TVA, coduri contabile	`Nomenclator`	`INomenclatorService`
Onboarding	Workflow-uri de onboarding companie (doar Application)	—	`IOnboardingService`
Dashboard	Agregări/indicatori pentru pagina principală (doar Application)	—	—
Logs	Audit logs de activitate (doar Application, DTO-uri)	—	—
Ai	Config integrare AI per companie (provider, API key, buget) pentru parsare de conținut	`AiIntegration`	`IAiServices`
Storage	Abstracție de object storage peste MinIO (doar Application)	—	`IObjectStorage`

Modulele Odoo-style

Șapte domenii sunt împachetate ca module separate sub src/Modules/. Fiecare e un .csproj care implementează IAsyModule, e descoperit prin assembly scan (AddAsyModules) și poate fi activat/dezactivat per-tenant cu filtrul RequireModule("modulekey").

Modul	Folder	Domeniu împachetat
Companies	`src/Modules/Asy.Modules.Companies`	Companies
Contacts	`src/Modules/Asy.Modules.Contacts`	Contacts
Banking	`src/Modules/Asy.Modules.Banking`	Banking
Clients	`src/Modules/Asy.Modules.Clients`	Clients (Application-only)
Efactura	`src/Modules/Asy.Modules.Efactura`	Efactura
Msign	`src/Modules/Asy.Modules.Msign`	Msign
Tasks	`src/Modules/Asy.Modules.Tasks`	Tasks

Asy.Modules.Companies e template-ul de copiat pentru module noi. Detalii în Clean Architecture.

Maparea pe frontend

Domeniile de backend au corespondent în asydata-app-frontend/src/features/. Câteva nume diferă:

Feature frontend	Domeniu backend
`banca`	Banking
`facturi`	Invoicing
`nomenclator`	Catalog
`messengers`	Telegram
`efactura`	Efactura
`partners`, `crm`, `contracts`, `clients`	omonime
`notifications`, `sharing`, `reminders`, `operations`	omonime
`tasks`, `projects`, `project-milestones`, `task-*`, `recurring-task-rules`	Tasks (split pe sub-feature-uri)
`billing`, `payments`	Billing / Payments
`documentTemplates`, `reference`, `logs`, `ai`, `aiTokens`	omonime

Vezi și

Clean Architecture — straturi + module Odoo-style
Multi-tenancy & RLS — izolarea pe firm_id
Flux event-driven — outbox → Kafka firm.events
Glosar — termenii de business
Integrări — SFS, MSign, Telegram, notificări