Domain Driven Design
Domain-Driven Design (DDD) is an approach to developing software for complex needs by deeply connecting the implementation to an evolving model of the core business concepts. Here's a breakdown of how DDD principles have been applied in Orderly:
- Client: Identified optionally by a Brazilian CPF.
- Payment: Represents a transaction that will be used with OHS. Has an associated status (perhaps initiated, processed, confirmed).
- Order: Represents a customer's request. It has associated status (Received, Preparing, Ready, Finalized).
- Service: Represents the production of food. It has associated products and a client.
- Notification: A medium for communication with the user and the restaurant. Will utilize an ACL for integration.
- Admin: Handles promotional strategies and stock management.
- Stock: Represents the available inventory of products.
- Product: Items like Hamburger, Fries, Soda, etc.
-
ProductDetails: For
Product, attributes likeName,Description,NutritionalInfo, etc., can be value objects. They don't have an identity on their own, but they describe a Product. -
PaymentDetails: For
Payment, attributes likeAmount,Currency,QRCodecan be value objects. -
NotificationContent: For
Notification, details likeMessage,Timestamp, andTypecould be value objects.
-
Check-in: Rooted at
Client, withOrderbeing part of the aggregate. -
Check-out: Rooted at
Order, which affects bothDeliverandProduction. -
Communication: Rooted at the
Notificationsystem, interfacing via an ACL. -
Billing: Rooted at
Payment, using ACL to conform with OHS. -
Admin: Rooted at
Admin, influencing theStock.
- ClientRegistered: Triggered when a client registers.
- ProductsSelected: Triggered when products are selected.
- OrderCreated: Triggered after order creation.
- PaymentProcessed: Triggered during the payment process.
- PaymentApproved: Triggered upon payment confirmation.
- StatusUpdatedToReceived: Triggered when order status changes.
- ClientNotified: Triggered to notify the client.
