E-Shop Architecture
ecommerce · whole model (1 arch file)
Diagram
Context mapContext map of ecommerce · blueprint v2.8 covering the whole model (1 arch files): 7 bounded contexts, 0 outside the selection, 11 dependencies, 11 of them carrying derived contract traffic over 13 service-to-service edges. 2 cross-context policy binding(s), 2 of them named in the hover of 2 edge(s). 1 reaction(s) have an operation bound to no context and are in no hover.Context mapecommercewhole model · 1 arch file(s) · 7 context(s) · 8 service(s) · 11 dependencies · 0 outsideconformist · HTTP ×1 operation(s) · Reads a customer's standing discounts while an order is being created, and strikes every line price with what comes back (customers.QRY002). Conformist in the strict sense: the order service holds the discount shape this context publishes, field for field under the same names, translates nothing and enforces none of Customers' rules. Downstream because nothing in Customers knows the order flow exists or was shaped by it - it publishes no event, so this dependency is a read made at the moment it is needed and nothing else. It is the dependency that prices the shop. A read that fails is not treated as a failure: the order flow substitutes an empty discount set and carries on at full list price with nobody told (customers.ASM003, counted by customers.KPI001, and the wider case customers.FN001). conformist · MSG ×2 operation(s) · via inventory.stock-reserved, orders.submitted · queues inventory-events, orders-events · Consumes Stock Reserved. It is the trigger for Send Order Confirmation (orders.CMD002) and the only thing that moves an Order from submitted to confirmed, which is this context's only terminal state. · policy "confirm-on-stock-reserved" (owned by Orders) reacts to Stock Reserved from Inventoryconformist · MSG ×2 operation(s) · via inventory.stock-reserved, orders.submitted · queues inventory-events, orders-events · Consumes Order Submitted. Reserve Stock (inventory.CMD001) reacts to it, so every reservation this context makes originates in an Orders event. · policy "reserve-on-order-submit" (owned by Inventory) reacts to Order Submitted from Ordersconformist · HTTP ×2 operation(s) · Reads product and category data for browse, search, and product pages.conformist · HTTP ×4 operation(s) · Reads a customer's orders to render order history and order detail, and calls Create Draft Order and Submit Order when the shopper checks out. The storefront decides nothing about an order: it carries the intent and Orders applies every rule that governs it. conformist · HTTP ×1 operation(s) · Reads stock levels to show availability on the product page.conformist · HTTP ×7 operation(s) · Carries the shopper's own account acts to the context that owns them: registering, and correcting their details afterwards. It also reads the profile back to render it, and the discounts on it - the same read the order flow makes when it prices, called here by the person the discounts belong to. Conformist in the strict sense - the storefront adopts the customer model whole, adds no field of its own and enforces none of the validation, which belongs to Customers. The shopper never sees a customer id; the storefront holds it and every other context in this model receives it. conformist · HTTP·MSG ×3 operation(s) · via checkout.item-added · queues storefront-events · Reads the current cart to render the cart page and the header cart badge, calls Add to Cart when the shopper presses the button, and subscribes to Item Added to Cart so the badge and the cart page stay fresh without polling. The storefront sends the SKU and the quantity; the price the line is charged at is captured by Checkout, not by the page that displayed it (storefront.ASM003). conformist · HTTP ×5 operation(s) · Calls the catalog admin commands directly, with no staging copy in between (shop-admin.DC001). Conformist in the strict sense: the back office adopts Catalog's product and category model whole, adds no concept of its own to what it sends, and applies none of the rules - every one of them belongs to Catalog. conformist · HTTP ×3 operation(s) · Reads the whole order book, not one customer's slice of it, and moves an order to its next status with Set Order Status (orders.CMD004). This is the only place in the model where the shop writes to an order rather than the shopper doing it, and the only write this back office makes outside the catalog. Conformist: the status vocabulary is Orders', the transition rules are Orders', and this context adds neither. conformist · HTTP ×6 operation(s) · Reads a customer's record while an operator is handling a question about their order, reads the standing discounts on the same screen, and reads the whole customer list - once as the customer list, and once to put a name against the customer id an order carries. Read-only in this model, and that is now a statement with a date on it. The running shop also closes accounts from here, and customers.DC003 has decided closure belongs on the storefront under an admin role instead. This list is therefore not the whole of what the back office calls: the delete it still has is a surface the decision retires, held as customers.FN002 rather than declared here as though it were settled. BC004BC004SUPPORTCheckoutCheckoutServiceservices 1inbound 1outbound 0BC001BC001CORECatalogProductQueryServiceProductCatalogAdminServiceservices 2inbound 2outbound 0BC007BC007GENERICCustomersCustomerServiceservices 1inbound 3outbound 0BC003BC003SUPPORTInventoryInventoryServiceservices 1inbound 2outbound 1BC002BC002COREOrdersOrderServiceservices 1inbound 3outbound 2BC006BC006SUPPORTShopAdminShopAdminWebAppservices 1inbound 0outbound 3BC005BC005SUPPORTStorefrontStorefrontWebAppservices 1inbound 0outbound 5UDUDUDUDUDUDUDUDUDUDUDHTTP ×1MSG ×2MSG ×2HTTP ×2HTTP ×4HTTP ×1HTTP ×7HTTP·MSG ×3HTTP ×5HTTP ×3HTTP ×6
Integration map8 of 8 service(s) · 19 link(s) · 4 channel(s) · implementation: 0 as-is · 0 wip · 0 to-be · 0 unclear · 8 unstated of 8. Scope: whole model (1 arch file). Messages run through 4 declared channel(s); 3 queue(s) read by one service each are chips on that service. 2 operation(s) on 2 service(s) face outward with no consumer in this selection; 1 event(s) sent with no receiver here - counts are relative to the selection, not to the system.Integration mapecommerce8 of 8 service(s) · 19 link(s) · 4 channel(s) · implementation: 0 as-is · 0 wip · 0 to-be · 0 unclear · 8 unstated of 8Scope: whole model (1 arch file). Messages run through 4 declared channel(s); 3 queue(s) read by one service each are chips on that service. 2 operation(s) on 2 service(s) face outward with no consumer in this selection; 1 event(s) sent with no receiver here - counts are relative to the selection, not to the system.MSG · 1 operation(s) via orders.submitted · queue inventory-events: Order SubmittedMSG · 1 operation(s) via inventory.stock-reserved · queue orders-events: Stock ReservedMSG · 1 operation(s) via checkout.item-added · queue storefront-events: Item Added to CartHTTP (inferred) · 1 operation(s): Reserve Stock - POST /inventory/reserve [Automated]HTTP (inferred) · 1 operation(s): Close Customer Account - DELETE /customers/{id} [User decision]MSG · 1 operation(s) via orders.submitted: Order SubmittedMSG · 1 operation(s) via orders.send-confirmation: Send Order Confirmation [Task type not stated]HTTP · 1 operation(s): Get Customer Discounts - GET /customers/{id}/discounts [Task type not stated]MSG · 1 operation(s) via inventory.stock-reserved: Stock ReservedMSG · 1 operation(s) via checkout.item-added: Item Added to CartHTTP · 2 operation(s): Get Product - GET /products/{sku} [Task type not stated], List Products - GET /products [Task type not stated]HTTP · 4 operation(s): Submit Order - POST /orders/{id}/submit [Automated], Create Draft Order - POST /orders [User decision], Get Order - GET /orders/{id} [Task type not stated], List Orders - GET /orders [Task type not stated]HTTP · 1 operation(s): Check Stock - GET /inventory/{sku}/stock [Task type not stated]HTTP · 2 operation(s): Add to Cart - POST /cart/items [Automated], Get Cart - GET /cart [Task type not stated]HTTP · 7 operation(s): Register Customer - POST /customers [User decision], Update Customer Details - PUT /customers/{id} [User decision], Sign In Customer - POST /customers/sign-in [User decision], Sign Out Customer - DELETE /customers/session [User decision], Get Customer Profile - GET /customers/{id} [Task type not stated], Get Customer Discounts - GET /customers/{id}/discounts [Task type not stated], Get Customer Session - GET /customers/session [Task type not stated]HTTP · 2 operation(s): Get Product - GET /products/{sku} [Task type not stated], List Products - GET /products [Task type not stated]HTTP · 3 operation(s): Publish Product - POST /admin/products [User decision], Update Product Price - PUT /admin/products/{sku}/price [User decision], Create Category - POST /admin/categories [User decision]HTTP · 3 operation(s): Set Order Status - PUT /orders/{id}/status [User decision], Get Order - GET /orders/{id} [Task type not stated], List Orders - GET /orders [Task type not stated]HTTP · 6 operation(s): Sign In Operator - POST /operators/sign-in [User decision], Sign Out Operator - DELETE /operators/session [User decision], Get Customer Profile - GET /customers/{id} [Task type not stated], Get Customer Discounts - GET /customers/{id}/discounts [Task type not stated], List Customers - GET /customers [Task type not stated], Get Operator Session - GET /operators/session [Task type not stated]orders.submittedtopic · Shop Event Busorders.submitted (MCH001) - topic · Shop Event Bus · 1 routing key(s) · 1 operation(s) travel on itinventory.stock-reservedtopic · Shop Event Businventory.stock-reserved (MCH002) - topic · Shop Event Bus · 1 routing key(s) · 1 operation(s) travel on itcheckout.item-addedtopic · Shop Event Buscheckout.item-added (MCH003) - topic · Shop Event Bus · 1 routing key(s) · 1 operation(s) travel on itorders.send-confirmationqueue · Shop Event Busorders.send-confirmation (MCH004) - queue · Shop Event Bus · 1 routing key(s) · 1 operation(s) travel on itexternal consumersinferredinferred - 2 operation(s) on 2 service(s) are exposed and no service in this selection calls them. The model does declare a consumer-only context (ShopAdmin, Storefront), but nothing there calls these.⇄ apiSVC001SVC001ProductQueryServiceopenapi 2▲ProductQueryService - Serves product and category data⇄ apiSVC002SVC002ProductCatalogAdminServiceopenapi 3▲ProductCatalogAdminService - Maintains the product range, prices, and category tree⇄ apiSVC003SVC003OrderServiceopenapi 5▲httpClient 1▼asyncapi 2▲ 1▼queue orders-eventsqueue orders-events (MCH005) - OrderService reads through itarazzoOrderService - Order commands and queries⇄ apiSVC004SVC004InventoryServiceopenapi 2▲asyncapi 1▲ 1▼queue inventory-eventsqueue inventory-events (MCH006) - InventoryService reads through itInventoryService - Reserve and release stock⇄ apiSVC005SVC005CheckoutServiceopenapi 2▲asyncapi 1▲CheckoutService - Cart and add-to-cart▣ webappSVC006SVC006StorefrontWebApphttpClient 16▼asyncapi 1▼queue storefront-eventsqueue storefront-events (MCH007) - StorefrontWebApp reads through itStorefrontWebApp - Server-rendered storefront. It calls the read side of every upstream context to compose a page, and the five customer-initiated commands a shopper triggers from one. ▣ webappSVC007SVC007ShopAdminWebApphttpClient 14▼ShopAdminWebApp - Back-office web app. It calls operations belonging to Catalog, Orders and Customers and holds nothing of its own: it publishes no event, exposes no operation and answers no query. ⇄ apiSVC008SVC008CustomerServiceopenapi 12▲CustomerService - The account API, and since authentication landed the shop's session API too. Two commands a person runs on their own record, one the shop runs on it for them, three reads - one of which prices every order in the shop - and six operations that issue, resolve and revoke a session for either kind of person. MSG ×1MSG ×1MSG ×1HTTP ×1HTTP ×1MSG ×1MSG ×1HTTP ×1MSG ×1MSG ×1HTTP ×2HTTP ×4 · 2 commands, 2 queriesHTTP ×1HTTP ×2 · 1 command, 1 queryHTTP ×7 · 4 commands, 3 queriesHTTP ×2HTTP ×3HTTP ×3 · 1 command, 2 queriesHTTP ×6 · 2 commands, 4 queries
Strategy gridNo context in this selection carries an evolution stage, so nothing can be placed.Strategy gridecommerce7 contexts - no evolution stages statedNo context in this selection carries an evolution stage, so nothing can be placed.BC001 (Catalog)BC002 (Orders)BC003 (Inventory)BC004 (Checkout)BC005 (Storefront)BC006 (ShopAdmin)BC007 (Customers)
Domain map5 domain(s) · 6 aggregated dependency(ies) · 1 crossing(s). 7 of 7 context(s) placed across 5 declared domain(s). 1 domain(s) carry no context in this selection. 4 dependency(ies) are internal to a domain and counted on its box, not drawn. Not shown: 2 of 6 edge labels had no free spot beside their edge - each is in that edge's tooltip.Domain map5 domain(s) · 6 aggregated dependency(ies) · 1 crossing(s)ecommerce7 of 7 context(s) placed across 5 declared domain(s). 1 domain(s) carry no context in this selection. 4 dependency(ies) are internal to a domain and counted on its box, notdrawn. Not shown: 2 of 6 edge labels had no free spot beside their edge - each is in that edge's tooltip.1 dep · conformist1 dep · conformist1 dep · conformist1 dep · conformist2 deps · conformist1 dep · conformistDOMAIN · 0 contextsdeliverydelivery - 0 context(s)DOMAIN · 1 contextcustomersCustomerscustomers - 1 context(s)DOMAIN · 2 contexts2 internalfulfilmentInventoryOrdersfulfilment - 2 context(s), 2 internal dependency(ies)DOMAIN · 2 contexts1 internalmerchandisingCatalogShopAdminmerchandising - 2 context(s), 1 internal dependency(ies)DOMAIN · 2 contexts1 internalshoppingCheckoutStorefrontshopping - 2 context(s), 1 internal dependency(ies)1 dep · conformist1 dep · conformist1 dep · conformist2 deps · conformist

Printed whole to fit the sheet. The report and the PDF delivered beside this page print it at reading size.

Context Map

  • conformist
  • U upstream (supplies) · D downstream (consumes)
  • HTTP·MSG ×n - derived from contracts
  • context kind - core · support · generic
  • Shop (7)
scroll to zoom · drag to pan