Product Map¶
The Product Map is the blueprint of the entire Yam3at platform: every domain, module, and capability, each in exactly one place. Every other document in this Bible — SRS modules, ERD, API endpoints, backlog — is derived from this map. If a feature is not on this map, it does not exist; if it is on the map, there is exactly one answer to "where does it belong?"
Yam3at is organized as 12 business domains following Domain-Driven Design. Deliberately, there is no "Customer module", "Vendor module", or "Admin module" — those are users, not domains. Customers, vendors, and admins all use the same domains through different permissions.
The three ownership rules¶
Rule 1 — Everything belongs somewhere
Nothing exists by itself. Every feature, screen, table, and endpoint maps to exactly one domain. If someone asks "where does Vendor Subscription live?" there is one exact answer (Vendor domain, billed through the Financial domain's payment engine).
Rule 2 — One owner per feature
Every feature has exactly one owning domain. Messaging belongs to Communication — not to Vendor, not to Customer, not to Admin. Everyone uses it; one domain owns it. The owner defines its data model, business rules, and API surface.
Rule 3 — Engines are shared
There are no "Vendor Notifications", "Customer Notifications", and "Admin Notifications". There is one Notification Engine used by everyone. The same applies to messaging, payments, files, and search. Shared engines are built once, in their owning domain, and consumed by all user types. This single principle saves months of development.
Domain overview¶
flowchart TB
subgraph Core["Core value"]
EVT["2 · Event<br/>the heart"]
MKT["3 · Marketplace<br/>discovery"]
BKG["5 · Booking<br/>quotes → bookings"]
end
subgraph Sides["The two sides"]
IDN["1 · Identity<br/>users & access"]
VND["4 · Vendor<br/>vendor business"]
end
subgraph Engines["Shared engines"]
FIN["6 · Financial<br/>all money"]
COM["7 · Communication<br/>messages & notifications"]
PLT["11 · Platform<br/>files · search · i18n · flags · audit"]
end
subgraph Leverage["Leverage layers"]
EXP["8 · Experience<br/>reviews · loyalty"]
INT["9 · Intelligence<br/>AI"]
OPS["10 · Operations<br/>admin · moderation · support"]
GRW["12 · Growth<br/>marketing · analytics"]
end
IDN --> EVT
IDN --> VND
EVT --> BKG
MKT --> BKG
VND --> MKT
BKG --> FIN
BKG --> COM
EVT --> COM
BKG --> EXP
EXP --> MKT
INT -.assists.-> EVT & MKT & BKG
OPS -.governs.-> VND & BKG & EXP
PLT -.serves.-> Core & Sides & Leverage
GRW -.measures.-> CoreReading the map: Identity lets people in. Marketplace helps customers discover what the Vendor domain publishes. Everything a customer does hangs off an Event. Booking converts intent (quotations) into commitments. Financial moves the money, Communication moves the words, Platform carries the infrastructure, and Experience / Intelligence / Operations / Growth make the loop trustworthy, smart, governed, and growing.
1 · Identity Domain¶
Everything related to who a user is and what they may do. Not "customers" or "vendors" — identity. First domain because everything else depends on it.
| Module / capability | Phase | SRS coverage |
|---|---|---|
| Registration & login (email, phone OTP, Google, Apple) | MVP | Identity & Auth |
| Email & phone verification | MVP | Identity & Auth |
| Password reset & account recovery | MVP | Identity & Auth |
| Profile management (customer & vendor users) | MVP | Identity & Auth |
| Roles & permissions (Customer, Vendor Owner, Vendor Staff, Admin roles) | MVP | Identity & Auth |
| Sessions & device management | MVP | Identity & Auth |
| Vendor KYC (commercial license verification workflow trigger) | MVP | Vendor Onboarding |
| Two-factor authentication (TOTP) | Scale | Identity & Auth |
| Organizations & team member accounts for vendors | Scale | Vendor Onboarding |
| Biometric login (mobile) | Scale | Identity & Auth |
| Consent & privacy center, data export/erasure | Scale | Identity & Auth |
2 · Event Domain¶
The heart of Yam3at. The Event is the core entity — everything a customer does belongs to an Event. See Event Lifecycle.
| Module / capability | Phase | SRS coverage |
|---|---|---|
| Event creation wizard (type, date, city, guests, budget) | MVP | Events & Planner |
| Event types taxonomy (wedding, corporate, يمعة family gathering, …) | MVP | Events & Planner |
| Event dashboard (linked quotations, bookings, payments, messages) | MVP | Events & Planner |
| Event documents & attachments | MVP | Events & Planner |
| Budget tracker (planned vs. quoted vs. committed vs. paid) | Scale | Events & Planner |
| Checklist & task lists (AI-seeded per event type) | Scale | Events & Planner |
| Guest list & RSVP tracking | Scale | Events & Planner |
| Event timeline & milestones | Scale | Events & Planner |
| Event templates & "rebook from previous event" | Scale | Events & Planner |
| Seating planner | Vision | — |
| QR invitations & digital guest check-in | Vision | — |
| Live event-day dashboard | Vision | — |
| Ticketing for public events | Vision | — |
3 · Marketplace Domain¶
Where discovery happens: what customers browse before they know which vendor they want.
| Module / capability | Phase | SRS coverage |
|---|---|---|
| Category tree (venues, catering, photography, decoration, …) | MVP | Marketplace & Search |
| Search & filters (city, area, category, budget, rating) | MVP | Marketplace & Search |
| Vendor listing pages (profile, gallery, services, packages) | MVP | Vendor Listings |
| Locations model (country → city → area, Kuwait first) | MVP | Marketplace & Search |
| Featured vendors (subscription benefit) | MVP | Marketplace & Search |
| Availability-date filtering (vendor calendar integration) | Scale | Marketplace & Search |
| Offers, bundles & smart packages | Scale | Vendor Listings |
| Sponsored listings & marketplace ads | Scale | Marketplace & Search |
| AR venue previews & 360° tours | Vision | — |
4 · Vendor Domain¶
Not about discovery — about helping vendors run their business on Yam3at. Subscriptions live here (the money movement is executed by Financial).
| Module / capability | Phase | SRS coverage |
|---|---|---|
| Vendor registration & business profile | MVP | Vendor Onboarding & Subscriptions |
| Commercial license upload & verification (Kuwait requirement) | MVP | Vendor Onboarding & Subscriptions |
| Admin approval workflow | MVP | Vendor Onboarding & Subscriptions |
| Subscription plans: Free / Basic / Professional / Enterprise | MVP | Vendor Onboarding & Subscriptions |
| Service catalog & portfolio/gallery management | MVP | Vendor Listings |
| Vendor dashboard (RFQs, bookings, messages, subscription) | MVP | Vendor Onboarding & Subscriptions |
| Basic vendor analytics (views, RFQs, acceptance rate) | MVP | Vendor Onboarding & Subscriptions |
| Availability calendar, blocked dates, Google Calendar sync | Scale | Vendor Listings |
| Branches & multi-location support | Scale | Vendor Onboarding & Subscriptions |
| Team members with roles | Scale | Vendor Onboarding & Subscriptions |
| Advanced analytics & performance benchmarks | Scale | — |
| Vendor CRM (leads, follow-ups, pipeline) | Vision | — |
5 · Booking Domain¶
Owns the path from intent to commitment. Quotations belong here — not in the Event domain. A quotation is a commercial negotiation; an event is what it serves.
| Module / capability | Phase | SRS coverage |
|---|---|---|
| Multi-vendor RFQ creation (from an Event) | MVP | Quotations |
| Vendor quote submission (price, notes, validity, attachments) | MVP | Quotations |
| Quotation states: Draft, Pending, Quoted, Negotiating, Accepted, Rejected, Expired, Cancelled | MVP | Quotations |
| Quote comparison view (side-by-side) | MVP | Quotations |
| Negotiation (counter-offers via messaging thread) | MVP | Quotations |
| Booking creation from accepted quote, with deposit | MVP | Booking |
| Booking states: Pending, Confirmed, Completed, Cancelled, Refund Requested | MVP | Booking |
| Cancellation policies & refund requests | MVP | Booking |
| Instant booking (skip RFQ for fixed-price packages) | Scale | Booking |
| Digital contracts attached to bookings | Scale | Booking |
| Milestone payments & escrow-backed bookings | Vision | — |
6 · Financial Domain¶
Money lives in one place. One payment engine — behind a PSP abstraction (MyFatoorah / Tap) — serves subscriptions, deposits, and refunds alike. KWD amounts use 3 decimal places.
| Module / capability | Phase | SRS coverage |
|---|---|---|
| Payment engine: KNET, Visa/Mastercard, Apple Pay, Google Pay | MVP | Payments |
| PSP abstraction layer (MyFatoorah / Tap swappable) | MVP | Payments, Integrations |
| Subscription billing, renewals, invoices | MVP | Payments |
| Booking deposit collection & payment records | MVP | Payments |
| Refund processing (admin-mediated) | MVP | Payments |
| Invoices & payment history (customer and vendor views) | MVP | Payments |
| Platform revenue reports | MVP | Admin & CMS |
| Booking commission (5% of total, captured from the deposit) | MVP | Payments |
| Basic vendor settlement (commission deduction + vendor payout) | MVP | Payments |
| Promo codes & coupons | Scale | — |
| Customer/vendor wallet | Scale | — |
| Multi-currency settlement (KWD → SAR, AED, …) | Scale | — |
| Automated escrow with milestone release, split payments, vendor financing | Vision | — |
7 · Communication Domain¶
Everything involving conversations and notifications. One messaging engine, one notification engine — shared by all user types (Rule 3).
| Module / capability | Phase | SRS coverage |
|---|---|---|
| In-app messaging: customer ↔ vendor, per event/quotation thread | MVP | Messaging & Notifications |
| Attachments in chat (images, PDF) | MVP | Messaging & Notifications |
| Notification engine: email + push (FCM), template-driven | MVP | Messaging & Notifications |
| Notification preferences per channel | MVP | Messaging & Notifications |
| Read receipts & typing indicators | Scale | Messaging & Notifications |
| SMS & WhatsApp notification channels | Scale | — |
| Voice notes in chat | Scale | — |
| Announcements & activity feed | Scale | — |
| Video calls / live consultations | Vision | — |
8 · Experience Domain¶
The often-forgotten layer that makes the marketplace trustworthy and sticky: reputation and retention.
| Module / capability | Phase | SRS coverage |
|---|---|---|
| Verified reviews & ratings (post-completion only) | MVP | Reviews |
| Vendor replies to reviews | MVP | Reviews |
| Review moderation & abuse reporting | MVP | Reviews, Admin & CMS |
| Favorites / saved vendors | MVP | Reviews |
| Review photos | Scale | Reviews |
| Referral program | Scale | — |
| Loyalty & rewards | Vision | — |
9 · Intelligence Domain¶
The AI brain. AI is woven into workflows, not bolted on as a chatbot. Entirely post-MVP by design — the MVP gathers the data that makes AI useful.
| Module / capability | Phase | SRS coverage |
|---|---|---|
| Vendor recommendations (budget, event type, location, history) | Scale | — |
| AI quote drafting for vendors | Scale | — |
| Search ranking signals | Scale | — |
| AI event planner (suggested checklist, timeline, budget split) | Scale | — |
| Pricing suggestions & demand insights for vendors | Vision | — |
| Conversation summaries for support/disputes | Vision | — |
| AI event designer & assistant | Vision | — |
10 · Operations Domain¶
Everything the business team needs to run the platform.
| Module / capability | Phase | SRS coverage |
|---|---|---|
| Admin dashboard (KPIs, pending approvals, activity) | MVP | Admin & CMS |
| Vendor approval queue (license review, approve/reject with reason) | MVP | Admin & CMS |
| User & vendor management (suspend, reactivate) | MVP | Admin & CMS |
| Content moderation (listings, reviews, reported content) | MVP | Admin & CMS |
| Dispute & refund-request handling | MVP | Admin & CMS |
| CMS: static pages, FAQ, banners, terms/privacy | MVP | Admin & CMS |
| Subscription plan administration (pricing, limits) | MVP | Admin & CMS |
| Support ticketing system | Scale | — |
| Fraud detection rules | Scale | — |
| Compliance reporting | Scale | — |
11 · Platform Domain¶
Infrastructure services that every other domain consumes. Invisible when working; catastrophic when missing.
| Module / capability | Phase | SRS coverage |
|---|---|---|
| File & media service (S3-compatible, image processing) | MVP | Architecture Overview |
| Search engine (Meilisearch indexing pipeline) | MVP | Marketplace & Search |
| Localization: Arabic/English, full RTL, translatable content | MVP | Arabic-first & RTL |
| Countries, currencies, timezones model (multi-country ready) | MVP | Tables |
| Audit logs (who did what, when) | MVP | Admin & CMS |
| Feature flags | MVP | Architecture Overview |
| Background jobs & queues (Redis/Horizon) | MVP | Architecture Overview |
| System settings & integrations registry | MVP | Integrations |
| API keys & rate limiting for partners | Vision | — |
| White-label deployment support | Vision | — |
12 · Growth Domain¶
What turns Yam3at from a product into a scalable business.
| Module / capability | Phase | SRS coverage |
|---|---|---|
| Product analytics events (funnels instrumented from day one) | MVP | Marketing Playbook |
| SEO-ready public pages (listings, categories, CMS) | MVP | Marketing Playbook |
| Email campaign integration | Scale | — |
| Promo campaigns & referral mechanics (with Experience/Financial) | Scale | — |
| A/B testing & experiments | Scale | — |
| Affiliate program | Vision | — |
Cross-domain ownership answers¶
Common "where does X live?" questions, answered once:
| Question | Answer |
|---|---|
| Vendor subscriptions? | Vendor owns plans & entitlements; Financial executes billing. |
| Quotations? | Booking — they are commercial negotiation, not event planning. |
| Reviews? | Experience — written about a Booking, displayed by Marketplace. |
| Notifications triggered by a quote? | Communication owns the engine; Booking emits the domain event. |
| Vendor gallery images? | Vendor owns the content; Platform stores the files. |
| Search? | Platform owns the engine; Marketplace owns relevance rules and filters. |
| Dispute over a booking? | Operations owns resolution; Financial executes any refund. |
Next: how the core entity moves through its life — Event Lifecycle.