FTGO

26
Pareto solutions
7
Exemplars
5 (α=0.5)
Clusters
0.89
HV ratio
0.457
Silhouette

Canonical reference (S*)

Canonical reference (S*)
— canonical reference (S*)
Richardson (2018), Microservices Patterns, cap. 2 — FTGO reference app
5 services · key: sstar_ftgo_primario
Metrics
Interface count1.000
Msg cohesion0.509
Domain cohesion0.733
Inter-svc calls0.000
Structural MQ0.074
Conceptual MQ0.229
BC penalty0.861
NMI (BC align.)0.091
Data ownership0.000
Verified facts
  • BCs contained: —
  • BCs fragmented: —
  • FK crossings between services: 3
  • Shared tables: RESTAURANTS
  • High-uncertainty classes: 0
Benefits
    Risks
      Services
      accounting-service:
      consumer-service:
      kitchen-service:
      order-service:
      restaurant-service:
      Services & data

      Exemplars

      #1#2#3#4#5#6#7
      Exemplar 1: Best BC compliance (cluster 1 medoid)
      Cluster medoid cluster medoid
      The system is split into six fragmented bounded contexts (Order, Kitchen, Delivery, Restaurant, Consumer, Accounting) distributed over 63 services, with low majority service shares (e.g., Order 0.08, Kitchen 0.25) and a cohesion metric CHM of 0.5086. Metrics show high modular quality (CMQ 0.9841) but low service modularity quality (SMQ 0.0629) and a high inter‑service relational number (IRN 60).
      63 services · Cluster 1 — best BC compliance (n=3) · key: run16_eps0.55_step0.10_ms2
      Metrics
      Interface count1.000
      Msg cohesion0.509
      Domain cohesion0.733
      Inter-svc calls60.000
      Structural MQ0.063
      Conceptual MQ0.984
      BC penalty0.622
      NMI (BC align.)0.202
      Data ownership0.000
      Verified facts
      • BCs contained: —
      • BCs fragmented: Accounting, Consumer, Delivery, Kitchen, Order, Restaurant
      • FK crossings between services: 0
      • Shared tables: CONSUMERS, ORDERS, RESTAURANTS, TICKETS
      • High-uncertainty classes: 40
      Benefits
      • Consolidating services within each bounded context to reach the 0.8 contained‑share threshold could raise cohesion and reduce the penalty_swm of 0.6218.
      • Eliminating the four shared tables would remove cross‑context data coupling.
      • Reducing the 48 singleton services would lower operational overhead and may improve SMQ.
      Risks
      • Twelve classes have entropy above the high‑uncertainty threshold (e.g., 0.9998), so reassigning them risks functional gaps.
      • The large number of singleton services (48) may increase deployment and monitoring complexity.
      • Creating new service boundaries could introduce foreign‑key crossings, which are currently zero.
      Services
      OrderAccountingService [Order]: Handles accounting operations related to orders, such as charging and refund processing.
      ConsumerManagementService [Consumer]: Manages consumer profiles and persistence through repository and service layers.
      ConsumerExceptionService: Defines exceptions for consumer‑related error conditions like not found or verification failure.
      ConsumerCommandService: Processes consumer service commands and provides configuration for command handling.
      KitchenTicketService [Kitchen]: Manages kitchen ticket lifecycle and publishes related domain events.
      ResultBuilderUtility: Provides generic builder and result patterns used across other services.
      +57 more services
      OrderDomainService: Represents the order aggregate and its line items within the domain model.
      OrderProcessingService: Processes orders and supplies configuration for order handling.
      RestaurantManagementService [Restaurant]: Manages restaurant data and publishes restaurant‑related domain events.
      DeliveryAccountService [Delivery]: Handles account information specific to the delivery bounded context.
      AccountAuthorizationErrorService: Represents a failure when an account cannot be authorized.
      AccountAuthorizationEventService: Emits an event when an account has been successfully authorized.
      AccountCommandService: Encapsulates commands that operate on accounts.
      AccountCreatedEventService: Publishes an event whenever a new account is created.
      AccountDisabledErrorService: Signals an error condition when an account is disabled.
      AccountingAuthorizationService [Accounting]: Executes internal commands to authorize account transactions within accounting.
      AccountCreationService: Handles the command to create new accounts.
      AuthorizationReversalService: Processes internal commands to reverse previously granted authorizations.
      AuthorizationRevisionService: Handles internal commands to revise existing authorizations.
      ConsumerCreatedEventService: Emits an event indicating that a consumer has been successfully created.
      OrderCancellationService: Processes CancelCommand to validate and update order status to cancelled.
      LineItemAdjustmentService: Handles ChangeLineItemQuantityCommand to modify quantities of items in an order line.
      MenuCatalogService: Provides CRUD operations and retrieval of MenuItem entities for restaurant menus.
      RestaurantProfileService: Manages core Restaurant data, including creation, updates, and deactivation.
      RestaurantVerificationService: Validates restaurant details during onboarding and raises RestaurantDetailsVerificationException on errors.
      RestaurantMenuService: Maintains the association between restaurants and their MenuItem collections, publishing menu changes.
      RestaurantPersistenceService: Offers persistence operations for Restaurant aggregates via RestaurantRepository.
      TicketLifecycleService: Coordinates creation and state transitions of Ticket objects throughout order fulfillment.
      TicketCreationEventService: Publishes TicketCreatedEvent when a new ticket is generated for processing.
      TicketLookupService: Retrieves tickets from storage and throws TicketNotFoundException when absent.
      TicketPickupEventService: Emits TicketPickedUpEvent when a ticket is collected for delivery.
      TicketPrepCompletedEventService: Publishes TicketPreparationCompletedEvent after ticket preparation finishes.
      TicketPrepStartedEventService: Emits TicketPreparationStartedEvent when ticket preparation begins.
      TicketPersistenceService: Provides storage and retrieval capabilities for Ticket aggregates via TicketRepository.
      TicketRevisionService: Handles TicketRevised actions to update ticket details and notify interested parties.
      DeliveryInfoService: Manages DeliveryInformation such as address and instructions linked to orders.
      MenuItemValidationService: Validates menu item identifiers and throws InvalidMenuItemIdException for invalid IDs.
      LineItemQuantityService: Processes LineItemQuantityChange objects to enforce business rules around quantity updates.
      MenuItemManagementService: Oversees the lifecycle of individual MenuItem records, including updates and deprecation.
      OptimisticLockingService: Handles OptimisticOfflineLockException by managing concurrency control for offline operations.
      AuthorizedCancelRequestService: Processes cancellation requests for orders that have already been authorized.
      CancelRequestProcessingService: Handles generic cancellation requests for orders.
      OrderEventPublishingService: Publishes order-related domain events to the messaging infrastructure.
      LineItemChangeQueueService: Queues and manages changes to order line items before they are applied.
      OrderMinimumValidationService: Validates that an order meets the required minimum amount before acceptance.
      OrderRetrievalService: Retrieves order details and handles scenarios where the order cannot be found.
      RejectedOrderCancelService: Processes cancellation requests for orders that were previously rejected.
      OrderPersistenceService: Provides persistence operations for storing and retrieving order data.
      OrderRevisionManagementService: Manages the lifecycle and state of revised orders within the system.
      OrderRevisionCreationService: Creates new revisions for existing orders based on change proposals.
      OrderRevisionProposalService: Handles proposals for revising orders, initiating the revision workflow.
      OrderRevisionRejectionService: Processes rejection of order revision proposals and notifies relevant parties.
      OrderRepositoryConfigService: Configures repository beans and settings for the order service layer.
      PaymentInfoService: Manages payment information associated with customer orders.
      RestaurantDomainService: Encapsulates core restaurant domain logic and attributes.
      RestaurantLookupService: Looks up restaurant information and handles not‑found errors.
      RestaurantDataAccessService: Provides data access operations for restaurant entities.
      RevisedOrderProcessingService: Processes revised orders, applying updates to the original order.
      RestaurantCreationService: Handles creation requests for new restaurant entries in the system.
      MenuItemCatalogService: Manages catalog information for individual menu items.
      RestaurantCoreService: Manages the lifecycle of the Restaurant aggregate, handling creation, updates, and retrieval of restaurant data.
      RestaurantMenuDomainService: Provides operations for maintaining a restaurant's menu, including adding, modifying, and removing menu items.
      RestaurantPersistenceGateway: Acts as the data access layer for Restaurant entities, persisting and loading restaurant information from storage.
      Services & data
      Exemplar 2: Fewest inter-service calls (cluster 5 medoid)
      Cluster medoid cluster medoid
      The current microservice decomposition for ftgo consists of 23 services distributed across six fragmented bounded contexts (Order, Kitchen, Delivery, Restaurant, Consumer, Accounting). The decomposition shows a moderate average class cohesion (CHM 0.505) and high class modular quality (CMQ 0.886) but a very low service modular quality (SMQ 0.016).
      23 services · Cluster 5 — fewest inter-service calls (n=13) · key: run35_eps0.75_step0.10_ms3
      Metrics
      Interface count1.667
      Msg cohesion0.505
      Domain cohesion0.755
      Inter-svc calls3.000
      Structural MQ0.016
      Conceptual MQ0.885
      BC penalty0.800
      NMI (BC align.)0.128
      Data ownership0.000
      Verified facts
      • BCs contained: —
      • BCs fragmented: Accounting, Consumer, Delivery, Kitchen, Order, Restaurant
      • FK crossings between services: 0
      • Shared tables: CONSUMERS
      • High-uncertainty classes: 40
      Benefits
      • The absence of foreign‑key crossings (n_fk_crossings = 0) eliminates the need for distributed transactions across services.
      • The relatively high class modular quality (CMQ = 0.886) suggests that most classes are well aligned with their bounded contexts, facilitating independent evolution.
      Risks
      • All bounded contexts are fragmented, with majority shares ranging from 0.33 to 0.75, indicating that responsibilities are spread over many services and may increase inter‑service coupling.
      • The service modular quality is very low (SMQ = 0.016), reflecting weak cohesion at the service level and a risk of high coordination overhead.
      • Several classes have entropy_norm close to 1 (e.g., OrderRevisionRejected 0.9998) indicating high uncertainty about their correct bounded‑context placement, which can lead to architectural drift.
      Services
      AccountingManagementService [Accounting]: Handles creation, authorization, revision, and reversal of financial accounts and related commands and events.
      OrderProcessingService [Delivery, Kitchen, Order, Restaurant]: Coordinates order lifecycle, line‑item changes, kitchen ticketing, and restaurant menu interactions for order fulfillment.
      ConsumerVerificationService: Validates consumer existence and verifies associated restaurant details, raising appropriate exceptions on failure.
      TicketManagementService: Manages the full ticket workflow in the kitchen, from creation through preparation start, completion, and pickup.
      EntityNotFoundService: Provides standardized error handling for missing domain entities such as orders, restaurants, and tickets.
      ConsumerManagementService [Consumer]: Maintains consumer profiles, persistence, and core consumer‑related operations.
      +17 more services
      AccountAuthorizationErrorService: Represents a failure when an account authorization attempt does not succeed.
      AccountDisabledErrorService: Indicates that an account has been disabled and cannot be used.
      ConsumerCreatedEventService: Publishes an event when a new consumer is successfully created.
      ConsumerCommandHandlerService: Executes incoming consumer‑related commands by delegating to appropriate handlers.
      ConsumerConfigurationService: Configures beans and settings required for the consumer service at application startup.
      CancelCommandService: Encapsulates a generic cancel operation command for use across services.
      ObjectBuilderService: Offers reusable builder utilities for constructing complex objects.
      DeliveryInformationService: Stores and provides delivery address and timing information for orders.
      MenuItemValidationErrorService: Signals that a provided menu item identifier is invalid, preventing further processing.
      OptimisticLockErrorService: Signals an optimistic locking conflict when concurrent offline updates collide.
      OrderAuthorizedCancelService: Represents a request to cancel an order that has already been authorized.
      OrderCancelRequestService: Represents a generic request to cancel an existing order.
      OrderMinimumViolationService: Indicates that an order does not satisfy the minimum amount or item count requirement.
      OrderRejectedCancelService: Represents a request to cancel an order that was previously rejected.
      OrderRevisionRejectionService: Handles the processing and notification of rejected order revisions.
      OrderRepositoryConfigurationService: Provides configuration and wiring of repository components for order management.
      OperationResultService: Encapsulates and standardizes the outcome representation of service operations.
      Services & data
      Exemplar 3: Fewest interfaces (cluster 2 medoid)
      Cluster medoid cluster medoid
      The current decomposition consists of 44 services distributed across six fragmented bounded contexts (Order, Kitchen, Delivery, Restaurant, Consumer, Accounting). Shared relational tables (CONSUMERS, ORDERS, RESTAURANTS) are accessed by multiple contexts, while there are no foreign‑key crossings between services.
      44 services · Cluster 2 — fewest interfaces (n=5) · key: run22_eps0.65_step0.05_ms2
      Metrics
      Interface count1.000
      Msg cohesion0.509
      Domain cohesion0.733
      Inter-svc calls36.000
      Structural MQ0.089
      Conceptual MQ0.950
      BC penalty0.674
      NMI (BC align.)0.183
      Data ownership0.000
      Verified facts
      • BCs contained: —
      • BCs fragmented: Accounting, Consumer, Delivery, Kitchen, Order, Restaurant
      • FK crossings between services: 0
      • Shared tables: CONSUMERS, ORDERS, RESTAURANTS
      • High-uncertainty classes: 40
      Benefits
      • A high CMQ of 0.9498 indicates strong internal cohesion within services.
      • The IFN metric of 1.0 shows that each service has a single inbound foreign‑key dependency, simplifying dependency management.
      Risks
      • All bounded contexts are marked as fragmented, which can increase the likelihood of distributed transactions and coordination overhead.
      • The presence of three shared tables across contexts creates implicit coupling that may lead to data consistency challenges.
      • Twelve classes have entropy_norm above 0.9, exceeding the high_uncertainty_entropy threshold of 0.6, indicating classification uncertainty that could affect service boundaries.
      Services
      KitchenTicketService [Kitchen]: Manages creation, tracking, and publishing of kitchen tickets for food preparation.
      OrderAccountingService [Accounting, Delivery, Order]: Handles creation, authorization, reversal, and revision of accounts related to orders and deliveries.
      RestaurantPersistenceService: Provides persistence operations for restaurant aggregates, including storage and retrieval.
      OrderManagementService: Processes orders and publishes corresponding domain events to other bounded contexts.
      RestaurantCoreService: Represents and manages core restaurant data within the domain.
      RestaurantMenuService: Maintains restaurant menu definitions and supports updates to menu items.
      +38 more services
      DomainExceptionService: Defines domain-specific not‑found exceptions for orders, restaurants, and tickets.
      MenuItemCatalogService [Restaurant]: Manages individual menu items within a restaurant's catalog.
      OrderRevisionService: Handles proposals and execution of order revisions, emitting related events.
      FinancialAccountingService: Provides accounting operations and configuration for financial transaction processing.
      ConsumerManagementService [Consumer]: Manages consumer profiles, including creation, retrieval, and persistence.
      ConsumerExceptionService: Defines consumer‑related exception types for not‑found and verification failures.
      ConsumerCommandService: Executes consumer service commands and applies service configuration.
      BuilderResultUtility: Offers generic builder pattern utilities and result handling helpers.
      OrderAggregateService: Encapsulates orders and their line items as a cohesive aggregate.
      RestaurantEventService: Coordinates restaurant operations and publishes related domain events.
      AccountAuthorizationExceptionService: Represents a failure when an account authorization attempt is unsuccessful.
      AccountDisabledExceptionService: Indicates that an account has been disabled and cannot be used.
      ConsumerCreatedEventService: Emits an event when a new consumer is successfully created.
      CancelCommandService: Encapsulates a command to cancel an operation such as an order.
      LineItemQuantityChangeService: Handles commands to modify the quantity of line items in an order.
      RestaurantVerificationExceptionService: Encapsulates validation errors when verifying restaurant details.
      TicketCreationEventService: Publishes events when a kitchen ticket is created.
      TicketPickupEventService: Emits events when a ticket is picked up by delivery staff.
      TicketPreparationCompletedService: Signals completion of ticket preparation.
      TicketPreparationStartedService: Signals the start of ticket preparation.
      TicketRevisionService: Manages revisions to kitchen tickets after changes.
      DeliveryInformationService: Provides delivery address and contact details for orders.
      InvalidMenuItemExceptionService: Handles errors when a referenced menu item ID does not exist.
      LineItemQuantityChangeEventService: Publishes events reflecting changes to line item quantities.
      OptimisticLockExceptionService: Handles concurrency lock failures in offline scenarios.
      AuthorizedOrderCancelService: Processes cancel requests that have been authorized for orders.
      OrderCancelRequestService: Receives requests to cancel an order.
      OrderLineItemChangeQueueService: Queues changes to order line items for asynchronous processing.
      OrderMinimumExceptionService: Signals when an order does not meet the minimum value requirement.
      RejectedOrderCancelService: Handles cancel requests for orders that have been rejected.
      OrderRepositoryService: Provides persistence operations for order aggregates.
      OrderRevisionProcessingService: Manages creation and application of order revisions.
      OrderRevisionRejectionService: Handles events when an order revision is rejected.
      OrderRepositoryConfigService: Configures repository beans for order‑related services.
      PaymentProcessingService: Handles storage and validation of customer payment details for orders.
      RevisedOrderHandlingService: Manages creation and persistence of revised order versions after modifications.
      RestaurantCreationService: Processes requests to register new restaurants and initializes their core data.
      RestaurantProfileService: Provides read‑only access to restaurant profile data and business attributes.
      Services & data
      Exemplar 4: Structural-Best
      Structural-Best constraint anchor
      The system is decomposed into 20 services distributed across six fragmented bounded contexts (Order, Kitchen, Delivery, Restaurant, Consumer, Accounting). Metrics show a domain cohesion (CHD) of 0.73, class cohesion (CHM) of 0.51, and a coupling metric (CMQ) of 0.82, while there are zero foreign‑key crossings between services.
      20 services · Cluster 4 — Structural-Best (n=2) · key: run28_eps0.75_step0.025_ms2
      Metrics
      Interface count1.000
      Msg cohesion0.509
      Domain cohesion0.733
      Inter-svc calls13.000
      Structural MQ0.123
      Conceptual MQ0.821
      BC penalty0.742
      NMI (BC align.)0.170
      Data ownership0.000
      Verified facts
      • BCs contained: —
      • BCs fragmented: Accounting, Consumer, Delivery, Kitchen, Order, Restaurant
      • FK crossings between services: 0
      • Shared tables: CONSUMERS, RESTAURANTS
      • High-uncertainty classes: 40
      Benefits
      • A CHD of 0.73 indicates relatively strong cohesion within each bounded context, supporting clearer ownership of domain concepts.
      • Zero foreign‑key crossings (n_fk_crossings = 0) removes the need for distributed transactions across services.
      Risks
      • All bounded contexts are marked as fragmented, which can increase inter‑service coupling and complicate evolution.
      • Twelve classes have very high entropy (≈0.99), reflecting uncertainty about their proper bounded‑context placement.
      • Two database tables (CONSUMERS, RESTAURANTS) are shared across services, which can create data coupling.
      Services
      ExceptionManagementService: Defines and groups domain-specific exception types for consumers, orders, restaurants, and tickets.
      KitchenTicketService [Kitchen]: Manages the lifecycle of kitchen tickets from creation through preparation and pickup events.
      AccountingAccountService [Accounting]: Processes account creation, authorization, reversal and revision commands and publishes related events.
      OrderManagementService [Delivery, Order]: Handles order creation, revision, line‑item quantity changes and delivery information coordination.
      OrderCancelRequestService: Represents commands to request cancellation of authorized or rejected orders.
      RestaurantMenuService [Restaurant]: Manages restaurant entities and their menus, including menu items.
      +14 more services
      RestaurantDomainService: Publishes restaurant domain events and provides restaurant service configuration.
      ConsumerManagementService [Consumer]: Provides CRUD operations and repository access for consumer aggregates.
      ConsumerCommandService: Handles consumer‑related command messages and configures the consumer service.
      ResultBuilderUtility: Offers generic builder pattern and result wrapper utilities for cross‑cutting concerns.
      AccountAuthorizationFailureService: Signals that an attempt to authorize an account has failed.
      AccountDisabledExceptionService: Indicates an error condition where an account is disabled.
      ConsumerCreatedEventService: Publishes an event when a new consumer aggregate is created.
      CancelCommandService: Encapsulates a generic cancel command used across bounded contexts.
      InvalidMenuItemExceptionService: Represents an error when a referenced menu item identifier is invalid.
      OptimisticLockExceptionService: Denotes a concurrency failure due to optimistic offline locking.
      OrderCancelRequestedService: Event indicating that a cancellation has been requested for an order.
      OrderLineItemChangeQueueService: Event that a change to an order line item has been queued for processing.
      OrderRevisionRejectedService: Event indicating that a proposed order revision was rejected.
      OrderServiceConfiguration: Configures the order service with its required repository beans.
      Services & data
      Exemplar 5: BC-Optimal
      BC-Optimal constraint anchor
      The current decomposition splits the system into six fragmented bounded contexts (Order, Kitchen, Delivery, Restaurant, Consumer, Accounting) distributed over 20 services. Cohesion (CHM = 0.5004) and service modularity quality (SMQ = 0.0506) are modest, and there are no foreign‑key crossings between services.
      20 services · Cluster 5 — fewest inter-service calls (n=13) · key: run31_eps0.75_step0.05_ms2__mover_2
      Metrics
      Interface count1.250
      Msg cohesion0.500
      Domain cohesion0.651
      Inter-svc calls5.000
      Structural MQ0.051
      Conceptual MQ0.872
      BC penalty0.775
      NMI (BC align.)0.484
      Data ownership0.000
      Verified facts
      • BCs contained: —
      • BCs fragmented: Accounting, Consumer, Delivery, Kitchen, Order, Restaurant
      • FK crossings between services: 0
      • Shared tables: CONSUMERS, RESTAURANTS
      • High-uncertainty classes: 40
      Benefits
      • Low foreign‑key crossings (0) reduces risk of distributed transactions.
      • Majority share up to 0.75 in the Restaurant context concentrates most classes in a single service, aiding local consistency.
      • Fragmentation keeps each context small (e.g., Order has 25 classes across 7 services), which can improve deployability.
      Risks
      • All contexts are marked fragmented, which may increase inter‑service communication (IRN = 5.0).
      • High entropy for 12 uncertain classes (entropy_norm > 0.9) indicates placement uncertainty.
      • Shared tables (CONSUMERS, RESTAURANTS) introduce potential data‑consistency challenges across services.
      Services
      OrderDeliveryManagement [Delivery, Order, Restaurant]: Manages the full order lifecycle, including creation, revision, line‑item changes, delivery information, and restaurant menu interactions.
      KitchenTicketService [Kitchen]: Handles kitchen tickets, tracks preparation status, and publishes ticket‑related domain events.
      AccountManagementService: Manages customer accounts, processes accounting commands, and handles account‑related events and authorizations.
      DomainExceptionService: Defines domain‑specific exception types for order, restaurant, and ticket error conditions.
      OrderCancellationEvents: Represents events that are raised when an order cancellation is requested after authorization or rejection.
      ConsumerManagementService [Consumer]: Provides CRUD operations for consumer data and persists consumer information.
      +14 more services
      ConsumerExceptionService: Defines consumer‑related exception types for not‑found and verification‑failure scenarios.
      ConsumerCommandService: Handles consumer service commands and configures command‑handling infrastructure.
      BuilderResultUtility: Provides generic builder pattern helpers and result encapsulation utilities.
      AccountAuthorizationFailureService: Represents the event when account authorization fails.
      AccountDisabledExceptionService: Represents the exception thrown when an account is disabled.
      ConsumerCreatedEventService: Emits an event whenever a new consumer is successfully created.
      AccountingCommandService [Accounting]: Executes internal accounting commands for authorizations and cancellations.
      RestaurantVerificationExceptionService: Represents the exception raised when restaurant details verification fails.
      MenuItemExceptionService: Represents the exception for invalid menu‑item identifiers.
      OptimisticLockExceptionService: Represents the exception thrown on optimistic concurrency lock failures.
      OrderCancelRequestedEventService: Emits an event when a cancellation request for an order is received.
      OrderLineItemChangeEventService: Emits an event when a change to an order line item is queued for processing.
      OrderRevisionRejectedEventService: Emits an event when a proposed order revision is rejected.
      OrderServiceConfiguration: Configures the order service with its required repository beans and related settings.
      Services & data
      Exemplar 6: Best BC alignment (cluster 3 medoid)
      Cluster medoid cluster medoid
      The proposed decomposition aligns each bounded context to its own set of microservices, preserving the contained Consumer context as a single service and exposing the fragmented contexts (Order, Kitchen, Delivery, Restaurant, Accounting) as multiple services according to their current spread. The overall class cohesion is moderate (CHM 0.615, CHD 0.753) while inter‑service coupling is low (IFN 1.667) and there are no foreign‑key crossings (n_fk_crossings 0), indicating the decomposition will not introduce heavy distributed transaction overhead.
      31 services · Cluster 3 — best BC alignment (n=3) · key: run36_eps0.75_step0.10_ms5__mover_2
      Metrics
      Interface count1.667
      Msg cohesion0.616
      Domain cohesion0.753
      Inter-svc calls29.000
      Structural MQ0.010
      Conceptual MQ0.938
      BC penalty0.767
      NMI (BC align.)0.462
      Data ownership0.000
      Verified facts
      • BCs contained: Consumer
      • BCs fragmented: Accounting, Delivery, Kitchen, Order, Restaurant
      • FK crossings between services: 0
      • Shared tables: RESTAURANTS
      • High-uncertainty classes: 40
      Benefits
      • Contained Consumer context (majority_share 1.0) becomes a single microservice, maximizing cohesion (CMQ 0.938) and minimizing inter‑service calls.
      • Fragmented contexts are already spread across multiple services (e.g., Order uses 10 services with majority_share 0.44), so keeping them as separate services respects existing boundaries and limits the need for data refactoring.
      • Zero foreign‑key crossings (n_fk_crossings 0) and a shared table only for Restaurants suggests that the decomposition will avoid distributed transactions and can rely on eventual consistency.
      Risks
      • High entropy in several classes (e.g., OrderRevisionRejected entropy_norm 0.9998) exceeds the high_uncertainty_entropy threshold (0.6), indicating potential misplacement of responsibilities across services.
      • Fragmented bounded contexts have low majority_share (e.g., Kitchen 0.25, Delivery 0.3333), which may lead to weak cohesion within individual services and increased coordination overhead.
      • Shared table "RESTAURANTS" is accessed by multiple contexts, which could become a source of contention if not isolated.
      Services
      AccountAuthorizationService: Manages creation, authorization, and revision of customer accounts and emits related domain events.
      OrderKitchenService [Consumer, Kitchen, Order]: Handles the full order lifecycle, consumer data, kitchen ticket generation, and order revisions.
      RestaurantMenuService [Restaurant]: Maintains restaurant menus and menu items, providing CRUD operations for menu data.
      TicketEventService: Publishes and processes ticket lifecycle events such as creation, preparation start/completion, and pickup.
      DeliveryEventPublisherService [Delivery]: Publishes domain events for orders, restaurants, and tickets to support delivery workflows.
      AccountAuthorizationFailureService: Represents and emits events when account authorization attempts fail.
      +25 more services
      AccountCommandService: Encapsulates commands that trigger account-related operations.
      AccountExceptionService: Signals errors when an account has been disabled.
      AccountingProcessingService: Performs accounting calculations and financial transaction processing.
      ConsumerCreatedEventService: Emits an event whenever a new consumer is created in the system.
      ConsumerExceptionService: Indicates that a requested consumer could not be found.
      ConsumerVerificationExceptionService: Signals failure of consumer verification processes.
      CancelCommandService: Processes cancellation commands for orders or related entities.
      RestaurantVerificationExceptionService: Raises errors when restaurant detail verification does not succeed.
      TicketExceptionService: Indicates that a requested ticket could not be located.
      BuilderUtilityService: Provides generic builder utilities for constructing domain objects.
      DeliveryInfoService: Stores and provides delivery address and instruction information.
      MenuItemExceptionService: Raises an error when a menu item identifier is invalid.
      ConcurrencyExceptionService: Signals optimistic locking conflicts during offline concurrency operations.
      AccountingCommandService [Accounting]: Handles internal accounting commands for authorizing orders and processing cancellation requests.
      OrderCancelRequestHandler: Handles incoming requests to cancel an order and initiates the cancellation workflow.
      OrderMinimumValidationService: Validates that an order meets the required minimum value and raises an exception when it does not.
      OrderLookupService: Retrieves orders by identifier and reports a not‑found error when the order does not exist.
      RejectedOrderCancelService: Processes cancellation requests for orders that have already been rejected.
      OrderRevisionProcessingService: Applies approved revisions to existing orders and updates the order state accordingly.
      OrderRevisionProposalService: Accepts proposals to modify an order and initiates the revision workflow.
      OrderRevisionRejectionService: Handles rejection of order revision proposals and notifies relevant parties.
      OrderRepositoryConfigurationService: Configures repository beans for the order domain and wires them into the order service.
      RestaurantLookupService: Retrieves restaurant data by ID and raises a not‑found error when the restaurant does not exist.
      OperationResultService: Encapsulates success or failure outcomes of domain operations and provides standardized result handling.
      RestaurantCreationService: Accepts requests to create new restaurant entities and persists them in the system.
      Services & data
      Exemplar 7: Compromise
      Compromise constraint anchor
      ['The system is split into 20 services across six fragmented bounded contexts, with no foreign‑key crossings between services.', 'Overall modularity is high (CMQ\u202f=\u202f0.822) while service cohesion is moderate (CHM\u202f=\u202f0.509) and coupling is moderate (CHD\u202f=\u202f0.733).']
      20 services · Cluster 4 — Structural-Best (n=2) · key: run28_eps0.75_step0.025_ms2__mover_2
      Metrics
      Interface count1.000
      Msg cohesion0.509
      Domain cohesion0.733
      Inter-svc calls13.000
      Structural MQ0.074
      Conceptual MQ0.822
      BC penalty0.736
      NMI (BC align.)0.482
      Data ownership0.000
      Verified facts
      • BCs contained: —
      • BCs fragmented: Accounting, Consumer, Delivery, Kitchen, Order, Restaurant
      • FK crossings between services: 0
      • Shared tables: CONSUMERS, RESTAURANTS
      • High-uncertainty classes: 40
      Benefits
      • A CMQ of 0.822 suggests the decomposition achieves strong overall modular quality.
      • The absence of foreign‑key crossings (0) reduces the need for distributed transactions.
      • Only two tables are shared across services, limiting data coupling.
      Risks
      • All bounded contexts are marked fragmented, indicating potential domain leakage and coordination overhead.
      • No context reaches the 0.8 contained‑share threshold (highest is Consumer at 0.6), so responsibilities are spread across multiple services, increasing integration complexity.
      • Twelve classes have high entropy (top 12 of 40) with confidence below 0.4, reflecting uncertainty in their bounded‑context assignment.
      Services
      DomainExceptionService: Provides shared exception types for domain errors such as missing consumers, orders, restaurants, and tickets.
      KitchenTicketService [Kitchen]: Manages kitchen tickets, publishing events from creation through preparation and pickup.
      AccountManagementService: Handles account lifecycle, including creation, authorization, and reversal of authorizations.
      OrderManagementService [Delivery, Order]: Coordinates order processing, revisions, line‑item changes, and delivery information.
      OrderCancellationService: Processes cancellation requests for both authorized and rejected orders.
      RestaurantMenuService [Restaurant]: Maintains restaurant entities and their menus, including menu items.
      +14 more services
      RestaurantProvisioningService: Creates new restaurant records and publishes related domain events.
      ConsumerManagementService [Consumer]: Manages consumer profiles and persistence operations.
      ConsumerCommandService: Handles consumer‑related commands and configures the consumer service.
      UtilityBuilderService: Offers generic builder and result utilities used across services.
      AuthorizationErrorService: Represents failures when account authorization cannot be completed.
      AccountStatusErrorService: Signals that an account is disabled and cannot be used.
      ConsumerEventService: Publishes the ConsumerCreated event when a new consumer is registered.
      AccountingCommandService [Accounting]: Executes internal accounting commands such as authorize and cancel.
      MenuItemErrorService: Throws an error when an invalid menu‑item identifier is used.
      OptimisticLockErrorService: Indicates optimistic offline lock conflicts during persistence operations.
      OrderCancelRequestService: Captures and processes requests to cancel existing orders.
      OrderLineItemQueueService: Queues changes to order line items for asynchronous handling.
      OrderRevisionRejectionService: Records and communicates the rejection of an order revision proposal.
      OrderRepositoryConfigService: Configures the order service with its required repository components.
      Services & data

      Pairwise comparisons

      1↔21↔31↔41↔51↔61↔72↔32↔42↔52↔62↔73↔43↔53↔63↔74↔54↔64↔75↔65↔76↔7
      Exemplar 1 vs Exemplar 2
      Interface count+0.6667
      Msg cohesion-0.0034
      Domain cohesion+0.0218
      Inter-svc calls-57.0000
      Structural MQ-0.0465
      Conceptual MQ-0.0989
      BC penalty+0.1780
      NMI (BC align.)-0.0738
      Data ownership+0.0000
      • Classes moved: 48
      • BCs fixed (A→B): —
      • BCs broken (A→B): —
      • Δ FK crossings: +0
      • Δ shared tables: -3
      Exemplar 1 vs Exemplar 3
      Interface count+0.0000
      Msg cohesion+0.0000
      Domain cohesion+0.0000
      Inter-svc calls-24.0000
      Structural MQ+0.0259
      Conceptual MQ-0.0343
      BC penalty+0.0517
      NMI (BC align.)-0.0189
      Data ownership+0.0000
      • Classes moved: 19
      • BCs fixed (A→B): —
      • BCs broken (A→B): —
      • Δ FK crossings: +0
      • Δ shared tables: -1
      Exemplar 1 vs Exemplar 4
      Interface count+0.0000
      Msg cohesion+0.0000
      Domain cohesion+0.0000
      Inter-svc calls-47.0000
      Structural MQ+0.0606
      Conceptual MQ-0.1634
      BC penalty+0.1202
      NMI (BC align.)-0.0318
      Data ownership+0.0000
      • Classes moved: 44
      • BCs fixed (A→B): —
      • BCs broken (A→B): —
      • Δ FK crossings: +0
      • Δ shared tables: -2
      Exemplar 1 vs Exemplar 5
      Interface count+0.2500
      Msg cohesion-0.0082
      Domain cohesion-0.0821
      Inter-svc calls-55.0000
      Structural MQ-0.0123
      Conceptual MQ-0.1123
      BC penalty+0.1533
      NMI (BC align.)+0.2820
      Data ownership+0.0000
      • Classes moved: 45
      • BCs fixed (A→B): —
      • BCs broken (A→B): —
      • Δ FK crossings: +0
      • Δ shared tables: -2
      Exemplar 1 vs Exemplar 6
      Interface count+0.6667
      Msg cohesion+0.1069
      Domain cohesion+0.0207
      Inter-svc calls-31.0000
      Structural MQ-0.0529
      Conceptual MQ-0.0465
      BC penalty+0.1454
      NMI (BC align.)+0.2605
      Data ownership+0.0000
      • Classes moved: 42
      • BCs fixed (A→B): Consumer
      • BCs broken (A→B): —
      • Δ FK crossings: +0
      • Δ shared tables: -3
      Exemplar 1 vs Exemplar 7
      Interface count+0.0000
      Msg cohesion+0.0000
      Domain cohesion+0.0000
      Inter-svc calls-47.0000
      Structural MQ+0.0114
      Conceptual MQ-0.1617
      BC penalty+0.1138
      NMI (BC align.)+0.2801
      Data ownership+0.0000
      • Classes moved: 44
      • BCs fixed (A→B): —
      • BCs broken (A→B): —
      • Δ FK crossings: +0
      • Δ shared tables: -2
      Exemplar 2 vs Exemplar 3
      Interface count-0.6667
      Msg cohesion+0.0034
      Domain cohesion-0.0218
      Inter-svc calls+33.0000
      Structural MQ+0.0723
      Conceptual MQ+0.0646
      BC penalty-0.1263
      NMI (BC align.)+0.0549
      Data ownership+0.0000
      • Classes moved: 38
      • BCs fixed (A→B): —
      • BCs broken (A→B): —
      • Δ FK crossings: +0
      • Δ shared tables: +2
      Exemplar 2 vs Exemplar 4
      Interface count-0.6667
      Msg cohesion+0.0034
      Domain cohesion-0.0218
      Inter-svc calls+10.0000
      Structural MQ+0.1070
      Conceptual MQ-0.0645
      BC penalty-0.0577
      NMI (BC align.)+0.0420
      Data ownership+0.0000
      • Classes moved: 26
      • BCs fixed (A→B): —
      • BCs broken (A→B): —
      • Δ FK crossings: +0
      • Δ shared tables: +1
      Exemplar 2 vs Exemplar 5
      Interface count-0.4167
      Msg cohesion-0.0048
      Domain cohesion-0.1040
      Inter-svc calls+2.0000
      Structural MQ+0.0342
      Conceptual MQ-0.0134
      BC penalty-0.0247
      NMI (BC align.)+0.3558
      Data ownership+0.0000
      • Classes moved: 13
      • BCs fixed (A→B): —
      • BCs broken (A→B): —
      • Δ FK crossings: +0
      • Δ shared tables: +1
      Exemplar 2 vs Exemplar 6
      Interface count+0.0000
      Msg cohesion+0.1103
      Domain cohesion-0.0012
      Inter-svc calls+26.0000
      Structural MQ-0.0064
      Conceptual MQ+0.0524
      BC penalty-0.0325
      NMI (BC align.)+0.3343
      Data ownership+0.0000
      • Classes moved: 27
      • BCs fixed (A→B): Consumer
      • BCs broken (A→B): —
      • Δ FK crossings: +0
      • Δ shared tables: +0
      Exemplar 2 vs Exemplar 7
      Interface count-0.6667
      Msg cohesion+0.0034
      Domain cohesion-0.0218
      Inter-svc calls+10.0000
      Structural MQ+0.0579
      Conceptual MQ-0.0629
      BC penalty-0.0642
      NMI (BC align.)+0.3539
      Data ownership+0.0000
      • Classes moved: 27
      • BCs fixed (A→B): —
      • BCs broken (A→B): —
      • Δ FK crossings: +0
      • Δ shared tables: +1
      Exemplar 3 vs Exemplar 4
      Interface count+0.0000
      Msg cohesion+0.0000
      Domain cohesion+0.0000
      Inter-svc calls-23.0000
      Structural MQ+0.0347
      Conceptual MQ-0.1291
      BC penalty+0.0686
      NMI (BC align.)-0.0129
      Data ownership+0.0000
      • Classes moved: 32
      • BCs fixed (A→B): —
      • BCs broken (A→B): —
      • Δ FK crossings: +0
      • Δ shared tables: -1
      Exemplar 3 vs Exemplar 5
      Interface count+0.2500
      Msg cohesion-0.0082
      Domain cohesion-0.0821
      Inter-svc calls-31.0000
      Structural MQ-0.0382
      Conceptual MQ-0.0780
      BC penalty+0.1016
      NMI (BC align.)+0.3009
      Data ownership+0.0000
      • Classes moved: 36
      • BCs fixed (A→B): —
      • BCs broken (A→B): —
      • Δ FK crossings: +0
      • Δ shared tables: -1
      Exemplar 3 vs Exemplar 6
      Interface count+0.6667
      Msg cohesion+0.1069
      Domain cohesion+0.0207
      Inter-svc calls-7.0000
      Structural MQ-0.0788
      Conceptual MQ-0.0122
      BC penalty+0.0938
      NMI (BC align.)+0.2794
      Data ownership+0.0000
      • Classes moved: 38
      • BCs fixed (A→B): Consumer
      • BCs broken (A→B): —
      • Δ FK crossings: +0
      • Δ shared tables: -2
      Exemplar 3 vs Exemplar 7
      Interface count+0.0000
      Msg cohesion+0.0000
      Domain cohesion+0.0000
      Inter-svc calls-23.0000
      Structural MQ-0.0145
      Conceptual MQ-0.1274
      BC penalty+0.0621
      NMI (BC align.)+0.2990
      Data ownership+0.0000
      • Classes moved: 33
      • BCs fixed (A→B): —
      • BCs broken (A→B): —
      • Δ FK crossings: +0
      • Δ shared tables: -1
      Exemplar 4 vs Exemplar 5
      Decomposition B moves 16 domain classes, chiefly restaurant and menu entities, from their original services to other services. This relocation reduces inter‑service remote calls by 8 (a benefit) but raises inter‑service foreign keys by 0.25 and degrades cohesion metrics, while modestly improving CMQ and NMI_filtered. Overall B trades lower call coupling for higher schema coupling and mixed cohesion effects.
      Interface count+0.2500
      Msg cohesion-0.0082
      Domain cohesion-0.0821
      Inter-svc calls-8.0000
      Structural MQ-0.0729
      Conceptual MQ+0.0511
      BC penalty+0.0331
      NMI (BC align.)+0.3138
      Data ownership+0.0000
      • Classes moved: 16
      • BCs fixed (A→B): —
      • BCs broken (A→B): —
      • Δ FK crossings: +0
      • Δ shared tables: +0
      Exemplar 4 vs Exemplar 6
      Interface count+0.6667
      Msg cohesion+0.1069
      Domain cohesion+0.0207
      Inter-svc calls+16.0000
      Structural MQ-0.1135
      Conceptual MQ+0.1169
      BC penalty+0.0252
      NMI (BC align.)+0.2924
      Data ownership+0.0000
      • Classes moved: 28
      • BCs fixed (A→B): Consumer
      • BCs broken (A→B): —
      • Δ FK crossings: +0
      • Δ shared tables: -1
      Exemplar 4 vs Exemplar 7
      B adds one class (AuthorizeCommandInternal) moving it from service 2 to service 13, increasing the service count from 4 to 7. This migration improves cohesion (CMQ +0.0017) and normalized mutual information (+0.312) and lowers the penalty (‑0.0065), but reduces service modular quality (SMQ ‑0.049).
      Interface count+0.0000
      Msg cohesion+0.0000
      Domain cohesion+0.0000
      Inter-svc calls+0.0000
      Structural MQ-0.0492
      Conceptual MQ+0.0017
      BC penalty-0.0065
      NMI (BC align.)+0.3119
      Data ownership+0.0000
      • Classes moved: 1
      • BCs fixed (A→B): —
      • BCs broken (A→B): —
      • Δ FK crossings: +0
      • Δ shared tables: +0
      Exemplar 5 vs Exemplar 6
      Interface count+0.4167
      Msg cohesion+0.1151
      Domain cohesion+0.1028
      Inter-svc calls+24.0000
      Structural MQ-0.0406
      Conceptual MQ+0.0658
      BC penalty-0.0079
      NMI (BC align.)-0.0215
      Data ownership+0.0000
      • Classes moved: 35
      • BCs fixed (A→B): Consumer
      • BCs broken (A→B): —
      • Δ FK crossings: +0
      • Δ shared tables: -1
      Exemplar 5 vs Exemplar 7
      B moves 15 domain classes, concentrating restaurant‑related entities in the restaurant service and removing consumer‑service exceptions, which raises cohesion metrics CHM (+0.008202) and CHD (+0.082148). B lowers the inter‑facade count IFN by 0.25 and reduces the penalty_swm by 0.0395, but it raises the inter‑service request number IRN by 8 and drops CMQ by 0.0495 and NMI_filtered by 0.0019.
      Interface count-0.2500
      Msg cohesion+0.0082
      Domain cohesion+0.0821
      Inter-svc calls+8.0000
      Structural MQ+0.0237
      Conceptual MQ-0.0495
      BC penalty-0.0395
      NMI (BC align.)-0.0019
      Data ownership+0.0000
      • Classes moved: 15
      • BCs fixed (A→B): —
      • BCs broken (A→B): —
      • Δ FK crossings: +0
      • Δ shared tables: +0
      Exemplar 6 vs Exemplar 7
      Interface count-0.6667
      Msg cohesion-0.1069
      Domain cohesion-0.0207
      Inter-svc calls-16.0000
      Structural MQ+0.0643
      Conceptual MQ-0.1152
      BC penalty-0.0317
      NMI (BC align.)+0.0196
      Data ownership+0.0000
      • Classes moved: 28
      • BCs fixed (A→B): —
      • BCs broken (A→B): Consumer
      • Δ FK crossings: +0
      • Δ shared tables: +1