DECOMPASS

Cargo

131
Pareto solutions
6
Exemplars
2 (α=0.5)
Clusters
0.59
HV ratio
0.407
Silhouette

Exemplars

#1#2#3#4#5#6
Exemplar 1: Data-Optimal
Data-Optimal constraint anchor
The system is decomposed into four bounded contexts—booking, routing, handling, and tracking—each marked as fragmented. Classes are distributed across 17 services, with the majority of classes in each context residing in service 8, but the majority share ranges from 0.1923 to 0.5833.
17 services · Cluster 1 — highest structural quality (n=96) · key: 16_10_18_40_57_565707
Metrics
Interface count2.000
Msg cohesion0.518
Domain cohesion0.642
Inter-svc calls158.000
Structural MQ0.268
Conceptual MQ0.492
BC penalty0.894
NMI (BC align.)0.084
Data ownership0.083
Verified facts
  • BCs contained: —
  • BCs fragmented: booking, handling, routing, tracking
  • FK crossings between services: 0
  • Shared tables: CARGO, LOCATION, VOYAGE
  • High-uncertainty classes: 60
Benefits
  • The cohesion metric CHM is 0.518, indicating moderate internal cohesion within services.
  • The coupling metric CHD is 0.642, reflecting acceptable inter-service coupling.
  • No foreign key crossings (n_fk_crossings 0) reduce the risk of distributed transaction complexity.
Risks
  • All bounded contexts are fragmented, with low majority shares (e.g., handling 0.1923), which can increase coordination overhead.
  • Shared tables CARGO, LOCATION, VOYAGE are accessed by multiple services, potentially leading to data consistency challenges.
  • Several classes have high uncertainty entropy (up to 0.9771) and low confidence in their bounded context assignment, indicating possible misplacement.
Services
CarrierMovementService: Manages carrier movement schedules and related value objects.
SpecificationEngineService: Provides composable business rule specifications for domain validation.
CargoAdministrationApi: Exposes administrative APIs for cargo registration and route candidate handling.
BookingFacadeService: Acts as a facade to coordinate booking operations and assemble routing DTOs.
VoyageManagementService: Handles voyage creation, leg management, and persistence of voyage data.
RoutingDomainService: Computes itineraries by applying route specifications to cargo routing.
+11 more services
GraphDataAccessService: Offers data access to graph structures used by pathfinding components.
GraphTraversalService: Executes graph traversal to determine transit paths and integrates external routing services.
CargoOperationsService [booking, handling, routing, tracking]: Orchestrates cargo booking, routing, handling events, and tracking across the application.
HandlingEventIngestionService: Consumes handling event registration attempts from JMS and file sources for processing.
TrackingDtoService: Defines DTOs and conversion logic for cargo tracking and handling events.
RoutingCommandService: Processes commands to assign routes and legs to cargos.
TrackingPresentationService: Converts domain tracking data into view models and adapts delivery events for presentation.
LocationDtoService: Assembles location DTOs from domain location entities.
LocationRepositoryService: Manages persistence and retrieval of location data identified by UN/LOCODE.
DomainExceptionService: Encapsulates domain-specific exception types for cargo and handling errors.
HandlingReportService: Parses handling reports and generates handling event data for the system.
Services & data
Exemplar 2: Highest structural quality (cluster 1 medoid)
Cluster medoid cluster medoid
The system is decomposed into four bounded contexts—booking, routing, handling, and tracking—each marked as fragmented. These contexts contain 28, 21, 26, and 12 classes respectively, distributed across 11, 8, 10, and 5 services.
15 services · Cluster 1 — highest structural quality (n=96) · key: 16_10_18_41_52_978824__mover_4
Metrics
Interface count1.429
Msg cohesion0.531
Domain cohesion0.672
Inter-svc calls138.000
Structural MQ0.231
Conceptual MQ0.577
BC penalty0.868
NMI (BC align.)0.308
Data ownership0.975
Verified facts
  • BCs contained: —
  • BCs fragmented: booking, handling, routing, tracking
  • FK crossings between services: 0
  • Shared tables: CARGO, LOCATION, VOYAGE
  • High-uncertainty classes: 60
Benefits
  • Each bounded context concentrates a set of domain concepts, e.g., the booking context groups 28 classes across 11 services, providing a logical domain boundary.
  • The tracking context has the highest majority share of 0.5833, indicating relatively cohesive service distribution within that context.
  • The overall Service Modularity Quality (SMQ) metric is 0.231, reflecting a baseline level of modularity across services.
Risks
  • All four bounded contexts are labeled fragmented, indicating significant cross‑service scattering of domain concepts.
  • Several classes exhibit high normalized entropy (≥0.9) and low confidence in their top bounded context, such as BookingService with entropy 0.9771 and confidence 0.3588, suggesting potential misallocation.
  • The three shared tables (CARGO, LOCATION, VOYAGE) are used across contexts, which can introduce distributed transaction challenges.
Services
SpecificationEngineService: Provides a composable specification engine for evaluating business rules across the domain.
VoyageRoutingService [routing]: Manages carrier movements, schedules, and voyage data to support routing decisions within the shipping domain.
ItineraryCandidateDtoService: Transforms itinerary candidate domain objects into DTOs for external communication and presentation.
CargoRoutingDtoService: Converts cargo routing information to and from DTOs for API exchange.
CargoTrackingDomain: Encapsulates cargo delivery, itinerary, route specifications, and handling activities to enable tracking and routing operations.
PathfinderGraphService: Offers graph data access and traversal algorithms to compute optimal routes for cargo movement.
+9 more services
TransitPathService: Represents edges and paths in a transit network, supporting route calculation logic.
CargoBookingTrackingService [booking, tracking]: Handles cargo booking, inspection, persistence, and provides tracking APIs for clients.
CargoTrackingDtoService: Converts cargo tracking and handling event data into DTOs for client consumption.
RoutingCommandService: Processes commands that assign routes and legs to cargos within the routing workflow.
BookingFacadeService: Exposes facade APIs for cargo booking, location registration, and administrative operations.
HandlingEventService [handling]: Manages handling event registration, storage, messaging, and reporting for cargo handling processes.
CargoExceptionService: Defines domain-specific exceptions for cargo, location, voyage, and handling event errors.
HandlingReportService: Generates and processes handling reports based on recorded handling events.
LocationCatalogService: Provides access to location data and sample locations for routing and booking purposes.
Services & data
Exemplar 3: Structural-Best
Structural-Best constraint anchor
The current architecture fragments the four bounded contexts (booking, routing, handling, tracking) across multiple services, with each context’s classes spread over 6‑7 services. A candidate decomposition would allocate each bounded context to its own microservice, consolidating the majority of its classes (e.g., 75 % of tracking classes are already in service 3).
7 services · Cluster 1 — highest structural quality (n=96) · key: 16_10_18_41_53_109302__unir_2
Metrics
Interface count0.000
Msg cohesion1.000
Domain cohesion1.000
Inter-svc calls81.000
Structural MQ0.125
Conceptual MQ0.440
BC penalty0.959
NMI (BC align.)0.100
Data ownership0.333
Verified facts
  • BCs contained: —
  • BCs fragmented: booking, handling, routing, tracking
  • FK crossings between services: 0
  • Shared tables: CARGO, LOCATION, VOYAGE
  • High-uncertainty classes: 60
Benefits
  • Cohesion metrics are maximal (CHM = 1.0, CHD = 1.0), indicating that grouping classes by bounded context yields highly cohesive services.
  • There are no foreign‑key crossings (n_fk_crossings = 0), so the new microservices can avoid distributed transactions.
  • The majority share within each bounded context is relatively high (tracking 0.75, handling 0.5769), so each new service would contain most of its domain logic, reducing inter‑service calls.
Risks
  • All bounded contexts are currently fragmented, meaning classes are scattered across services, so consolidating will require substantial refactoring.
  • Several classes have high uncertainty entropy (≥0.9) and low confidence in their top bounded context, e.g., BookingService (entropy 0.9771, confidence 0.3588), posing risk of misplacement.
  • Shared tables (CARGO, LOCATION, VOYAGE) are used by multiple contexts, which may introduce data consistency challenges when the contexts become independent services.
Services
VoyageManagementService: Manages voyage definitions, assigns voyage numbers, and persists voyage data.
RoutingAndItineraryService: Calculates optimal itineraries, validates route specifications, and manages carrier movement schedules.
SpecificationEngineService: Offers composable business rule specifications for querying and validation across the domain model.
CargoBookingTrackingService [booking, handling, routing, tracking]: Handles cargo booking, registers handling events, performs cargo inspection, and provides tracking information through REST APIs.
CargoRoutingFacadeService: Provides a façade for processing cargo routing requests, itinerary candidate selection, and related booking commands.
CargoExceptionService: Defines and centralizes domain-specific exception types for unknown cargo, location, voyage, and handling event errors.
+1 more service
GraphPathfinderService: Supplies graph data access and traversal services to compute optimal paths for routing and navigation.
Services & data
Exemplar 4: Compromise
Compromise constraint anchor
The candidate decomposition separates the system into four fragmented bounded contexts—booking, routing, handling, and tracking. Cohesion metrics CHM and CHD are perfect (1.0) while service modularity quality SMQ is low (0.1809), indicating strong internal cohesion but limited modular separation.
19 services · Cluster 1 — highest structural quality (n=96) · key: 16_10_18_42_00_901869__mover_0
Metrics
Interface count0.000
Msg cohesion1.000
Domain cohesion1.000
Inter-svc calls149.000
Structural MQ0.181
Conceptual MQ0.656
BC penalty0.869
NMI (BC align.)0.284
Data ownership0.767
Verified facts
  • BCs contained: —
  • BCs fragmented: booking, handling, routing, tracking
  • FK crossings between services: 0
  • Shared tables: CARGO, LOCATION, VOYAGE
  • High-uncertainty classes: 60
Benefits
  • Perfect cohesion (CHM=1.0, CHD=1.0) reduces internal complexity within each service.
  • Zero foreign‑key crossings (n_fk_crossings=0) minimizes distributed transaction overhead.
  • Only three tables (CARGO, LOCATION, VOYAGE) are shared across contexts, limiting cross‑context data coupling.
Risks
  • All bounded contexts are fragmented, meaning classes are spread across many services and coupling is high.
  • Twelve classes have high uncertainty entropy (≥0.9), such as BookingService with entropy_norm 0.9771, risking misplacement across bounded contexts.
  • Shared tables across contexts may cause data‑consistency challenges and require coordination.
Services
HandlingReportService: Generate and provide handling reports for cargo handling events.
LogisticsCoreService: Define core logistics value objects such as delivery, schedule, locations and UN/LOCODE identifiers.
SpecificationEngineService: Offer reusable specification composition and evaluation for domain queries.
CargoRoutingDtoService: Transform cargo routing domain objects into DTOs for external communication.
BookingFacadeService: Expose booking operations through a façade for client layers.
GraphPersistenceService: Manage graph data access and provide a context for path‑finding operations.
+13 more services
RoutingEngineService: Compute transit paths using graph traversal and external routing services.
HandlingEventService [handling]: Register, store, query handling events and supply tracking views for cargo.
VoyageManagementService [routing]: Maintain voyage definitions, repositories and sample data for routing calculations.
CargoBookingTrackingService [booking, tracking]: Handle cargo booking, inspection, tracking DTOs and REST endpoints.
MessagingInfrastructureService: Configure JMS infrastructure and dispatch application events across services.
CargoAdminService: Provide administrative commands for cargo registration, leg management and route assignment.
TrackingCommandService: Represent and validate commands that initiate cargo tracking operations.
RoutingDomainService: Define carrier movements, route specifications and perform routing calculations.
LocationManagementService: Persist and retrieve location entities from the data store.
HandlingEventIngestionService: Scan upload directories, consume registration attempts and process handling event registrations.
ItineraryManagementService: Build, evaluate and expose itineraries and leg DTOs for routing candidates.
LocationDtoService: Convert location domain objects into DTOs for external APIs.
DomainExceptionService: Define domain‑specific exceptions for handling events, cargo, locations and voyages.
Services & data
Exemplar 5: Highest conceptual quality (cluster 2 medoid)
Cluster medoid cluster medoid
The proposed decomposition extracts four microservices, each aligned with one of the fragmented bounded contexts: booking, routing, handling, and tracking. Each microservice would contain the classes and services currently spread across the 40 existing services, consolidating them according to the context spreads.
40 services · Cluster 2 — highest conceptual quality (n=35) · key: run32_eps0.75_step0.05_ms3__mover_0
Metrics
Interface count1.667
Msg cohesion0.632
Domain cohesion0.716
Inter-svc calls147.000
Structural MQ0.012
Conceptual MQ0.881
BC penalty0.782
NMI (BC align.)0.376
Data ownership0.483
Verified facts
  • BCs contained: —
  • BCs fragmented: booking, handling, routing, tracking
  • FK crossings between services: 0
  • Shared tables: CARGO, LOCATION, VOYAGE
  • High-uncertainty classes: 60
Benefits
  • Cohesion metrics (CHM = 0.6316, CHD = 0.7161) indicate moderate to high internal cohesion for the resulting services.
  • The absence of foreign-key crossings (n_fk_crossings = 0) reduces the need for distributed transactions across services.
  • Consolidating classes per context lowers the number of inter-service calls, as the current fragmented status shows many classes spread across multiple services.
Risks
  • All bounded contexts are marked as fragmented, meaning many classes are currently shared across multiple services, which may cause high coupling after decomposition.
  • Twelve classes have high uncertainty entropy (≥ 0.9), indicating ambiguous ownership and risk of misallocation in the new service boundaries.
  • Shared tables (CARGO, LOCATION, VOYAGE) are used by multiple contexts, which can introduce data consistency challenges when each context becomes an independent microservice.
Services
CargoBookingRoutingService [booking, routing]: Manages cargo booking, routing, voyage scheduling, and handling event persistence.
ItineraryPlanningService: Provides itinerary planning and route candidate generation for cargo shipments.
RoutingGraphService [handling]: Computes optimal transit paths using a graph data model and external routing services.
SpecificationEngine: Evaluates domain specifications to enforce business rules across aggregates.
HandlingEventRegistration: Receives and processes handling event registration attempts from external sources.
CargoAdministrationService: Exposes administrative APIs for cargo booking, route assignment, and related commands.
+34 more services
CargoTrackingService [tracking]: Handles cargo tracking requests and validates tracking commands.
DomainExceptionCatalog: Defines domain‑specific exception types used throughout the cargo domain.
PathfinderApplicationContext: Bootstraps the application context for path‑finding components.
GraphDaoStub: Provides an in‑memory stub implementation of the graph data access object for testing.
CargoInspectionService: Performs cargo inspection and evaluates cargo status against specifications.
CargoRepositoryService: Persists and retrieves cargo aggregates from the underlying data store.
DeliveryService: Models the delivery outcome and related data for a cargo shipment.
HandlingActivityService: Represents handling activity details within the cargo handling process.
RouteSpecificationService: Defines route constraints and validation rules for cargo itineraries.
TrackingIdService: Encapsulates the tracking identifier value object used to locate cargo.
HandlingEventService: Represents a handling event entity and its lifecycle within the domain.
LocationRepositoryService: Manages persistence and retrieval of location entities.
UnLocodeService: Encapsulates the UN/LOCODE identifier for geographic locations.
CarrierMovementService: Models carrier movements between locations as part of voyage planning.
DomainEntityService: Provides the base class for all domain entities in the model.
DomainEventService: Provides the base class for domain events emitted by aggregates.
ValueObjectService: Provides the base class for immutable value objects used across the domain.
CargoHandledConsumerService: Consumes messages indicating cargo handling events from the messaging layer.
MessagingJmsConfigService: Configures JMS infrastructure for the application's messaging needs.
JmsApplicationEventsService: Implements application‑wide events using JMS as the transport mechanism.
CargoRepositoryJPAService: Provides a JPA implementation of the cargo repository interface.
LocationRepositoryJPAService: Provides a JPA implementation of the location repository interface.
SampleLocationsProvider: Supplies sample location data for application initialization and testing.
SampleVoyagesProvider: Supplies sample voyage data for application initialization and testing.
UploadDirectoryScannerService: Scans configured directories for newly uploaded files to be processed.
HandlingReportService: Represents handling report aggregates and their core operations.
HandlingReportProcessingService: Processes handling reports, transforming raw data into domain objects.
HandlingReportProcessingImpl: Concrete implementation of handling report processing logic.
HandlingReportParserService: Parses raw handling report files into structured domain entities.
CargoTrackingFacade: Exposes cargo tracking DTOs and delegates graph traversal for tracking queries.
CargoTrackingDtoConverter: Converts cargo tracking domain objects into Data Transfer Objects.
HandlingEventDtoService: Provides DTO representation for handling events used in external APIs.
CargoTrackingViewAdapter: Adapts cargo tracking data for presentation in UI views.
InterfacesApplicationContext: Bootstraps the application context for interface adapters and inbound ports.
Services & data
Exemplar 6: BC-Optimal
BC-Optimal constraint anchor
['The system is decomposed into four bounded contexts—booking, routing, handling, tracking—each marked as fragmented with low majority service share (0.1429 to 0.25) and spread across many services.', 'Overall, the architecture exhibits a high CMQ of 0.9246 and zero foreign‑key crossings, but a sizable set of classes (12 of 60) have high entropy (>0.9) indicating uncertainty about their proper context.']
58 services · Cluster 2 — highest conceptual quality (n=35) · key: run25_eps0.65_step0.10_ms2__mover_0
Metrics
Interface count1.250
Msg cohesion0.609
Domain cohesion0.666
Inter-svc calls195.000
Structural MQ0.037
Conceptual MQ0.925
BC penalty0.719
NMI (BC align.)0.444
Data ownership1.067
Verified facts
  • BCs contained: —
  • BCs fragmented: booking, handling, routing, tracking
  • FK crossings between services: 0
  • Shared tables: CARGO, LOCATION, VOYAGE
  • High-uncertainty classes: 60
Benefits
  • Zero foreign‑key crossings (0) eliminates the need for distributed transactions across services.
  • The CMQ metric of 0.9246 reflects strong modular quality and cohesion across the decomposition.
  • Low majority service shares (e.g., booking 0.1429, routing 0.0952) indicate that no single service dominates a context, supporting independent scaling.
Risks
  • Twelve classes have entropy_norm above 0.9, exceeding the high‑uncertainty threshold of 0.6, which may lead to misplacement across bounded contexts.
  • All four bounded contexts are labeled as fragmented, suggesting limited internal cohesion.
  • The three shared tables (CARGO, LOCATION, VOYAGE) are accessed by multiple contexts, creating potential data coupling.
Services
SpecificationEngineService [booking]: Evaluates and composes business rule specifications using the Specification pattern.
CargoBookingService: Creates and manages cargo bookings and assembles routing DTOs for client communication.
ExternalRoutingEngineService: Obtains transit paths and performs external routing calculations for cargo shipments.
GraphTraversalService: Provides data access and traversal algorithms over the routing graph.
CargoHandlingService [handling]: Handles registration, persistence, and inspection of cargo handling events.
LocationCatalogService: Offers CRUD operations for location data and persists locations via JPA.
+52 more services
DomainExceptionService: Defines domain-specific exceptions for cargo, location, voyage, and handling event errors.
CargoEventConsumerService: Consumes cargo-handled events and triggers inspection workflows.
HandlingReportService: Parses raw handling reports and generates structured handling report objects.
CargoRoutingService [routing]: Creates cargo instances, assigns routes, and coordinates booking with routing logic.
HandlingEventRegistrationService: Processes handling event registration attempts and coordinates consumer handling.
ItineraryCandidateService: Assembles DTOs for route candidates and itinerary proposals used in routing decisions.
CargoAdministrationService: Exposes administrative APIs for cargo booking management and route assignment commands.
CargoTrackingService [tracking]: Provides tracking endpoints, validates track commands, and returns cargo status.
TransitEdgeModelService: Models a transit edge linking locations and voyages within the routing graph.
PathfinderConfigService: Initializes the Spring application context for pathfinding components.
GraphDAOStubService: Supplies a stub implementation of GraphDAO for testing routing functionality.
DddSampleConfigService: Configures the application context for the DDD sample application.
CargoDomainService: Represents the Cargo aggregate with its state and domain behavior.
CargoRepositoryService: Persists and retrieves Cargo aggregates from the data store.
DeliveryOrchestrationService: Coordinates the final delivery of cargo to the consignee, ensuring all required steps are completed.
HandlingActivityProcessingService: Processes handling activities such as loading, unloading, and customs checks for cargo movements.
ItineraryManagementService: Creates, validates, and manages itineraries that define the planned route for cargo shipments.
LegRoutingService: Determines and provides individual legs of a cargo route, linking voyages and locations.
RouteSpecificationService: Defines the constraints and requirements that a cargo route must satisfy, such as origin, destination, and deadline.
TrackingIdentifierService: Generates and resolves unique tracking identifiers used to trace cargo throughout its journey.
HandlingEventProcessingService: Records and processes handling events that occur during cargo handling, updating cargo status accordingly.
HandlingEventFactoryService: Creates handling event instances based on input data, encapsulating business rules for event creation.
HandlingHistoryService: Aggregates and provides the chronological history of handling events for a given cargo.
UnLocodeCatalogService: Maintains a catalog of UN/LOCODE location codes and provides lookup services for location identification.
CarrierMovementService: Manages carrier movement schedules, linking voyages to specific departure and arrival times.
ScheduleManagementService: Handles creation and maintenance of schedules for voyages and carrier movements.
VoyageManagementService: Administers voyage entities, including their numbers, routes, and associated carrier movements.
VoyageNumberService: Generates and validates unique voyage numbers used to identify individual voyages.
VoyageRepositoryService: Provides persistence and retrieval operations for voyage aggregates.
DomainEntityRegistryService: Registers and tracks domain entities, ensuring consistent identity management across the system.
DomainEventService: Publishes and subscribes to domain events, enabling reactive communication between bounded contexts.
ValueObjectService: Defines and validates immutable value objects used throughout the domain model.
MessagingJmsConfigService: Configures JMS messaging infrastructure for application event propagation.
JmsApplicationEventsService: Handles sending and receiving of application events over JMS channels.
CargoPersistenceService: Provides JPA‑based storage and retrieval of cargo aggregates.
VoyagePersistenceService: Manages JPA persistence for voyage entities.
SampleDataGenerationService: Generates synthetic sample data for development and testing.
SampleLocationCatalogService: Supplies a catalog of sample location records.
SampleVoyageCatalogService: Provides a collection of sample voyage definitions.
LegTransferService: Handles conversion and transport of Leg DTO objects.
LocationTransferService: Manages mapping and transfer of Location DTOs.
LocationDtoAssemblerService: Assembles Location DTOs from domain entities and vice versa.
RegistrationCommandService: Processes registration command objects for creating new registrations.
UploadDirectoryScanningService: Scans the upload directory for new files and publishes discovery events.
HandlingReportGenerationService: Generates handling reports based on processed handling events.
HandlingReportProcessingService: Processes and persists handling report data for downstream consumption.
CargoTrackingDtoAdapterService: Adapts CargoTrackingDTO objects for use with graph traversal operations.
CargoTrackingDtoConversionService: Converts between CargoTracking domain models and their DTO representations.
CargoTrackingRestApiService: Exposes cargo tracking functionality through a RESTful API.
HandlingEventDtoService: Provides DTO representation and serialization for handling events.
CargoTrackingViewAdapterService: Adapts cargo tracking data for presentation in UI views.
InterfacesApplicationContextService: Manages the Spring application context for interface‑based components.
Services & data

Pairwise comparisons

1↔21↔31↔41↔51↔62↔32↔42↔52↔63↔43↔53↔64↔54↔65↔6
Exemplar 1 vs Exemplar 2
Interface count-0.5714
Msg cohesion+0.0131
Domain cohesion+0.0296
Inter-svc calls-20.0000
Structural MQ-0.0366
Conceptual MQ+0.0852
BC penalty-0.0259
NMI (BC align.)+0.2235
Data ownership+0.8917
  • Classes moved: 30
  • BCs fixed (A→B): —
  • BCs broken (A→B): —
  • Δ FK crossings: +0
  • Δ shared tables: +0
Exemplar 1 vs Exemplar 3
Decomposition B moves 38 classes—including core cargo entities such as Delivery, Itinerary and Leg—from service 12 to service 1, which raises cohesion (CHM +0.482, CHD +0.358) and cuts inter‑service relationships (IRN ‑77). However B lowers service‑quality metrics (SMQ ‑0.143, CMQ ‑0.052) and raises penalties (penalty_swm +0.065, pen_data +0.25), so modular quality is reduced despite better decoupling.
Interface count-2.0000
Msg cohesion+0.4821
Domain cohesion+0.3576
Inter-svc calls-77.0000
Structural MQ-0.1425
Conceptual MQ-0.0522
BC penalty+0.0652
NMI (BC align.)+0.0160
Data ownership+0.2500
  • Classes moved: 38
  • BCs fixed (A→B): —
  • BCs broken (A→B): —
  • Δ FK crossings: +0
  • Δ shared tables: +0
Exemplar 1 vs Exemplar 4
B relocates 28 classes, boosting cohesion (CHM +0.482, CHD +0.358) and lowering inter‑service coupling (IFN –2, IRN –9) while keeping foreign‑key crossings and shared tables unchanged. However, B slightly reduces service‑quality (SMQ –0.087) and raises data‑penalty (pen_data +0.683).
Interface count-2.0000
Msg cohesion+0.4821
Domain cohesion+0.3576
Inter-svc calls-9.0000
Structural MQ-0.0872
Conceptual MQ+0.1635
BC penalty-0.0249
NMI (BC align.)+0.1999
Data ownership+0.6833
  • Classes moved: 28
  • BCs fixed (A→B): —
  • BCs broken (A→B): —
  • Δ FK crossings: +0
  • Δ shared tables: +0
Exemplar 1 vs Exemplar 5
Interface count-0.3333
Msg cohesion+0.1138
Domain cohesion+0.0737
Inter-svc calls-11.0000
Structural MQ-0.2559
Conceptual MQ+0.3884
BC penalty-0.1119
NMI (BC align.)+0.2923
Data ownership+0.4000
  • Classes moved: 46
  • BCs fixed (A→B): —
  • BCs broken (A→B): —
  • Δ FK crossings: +0
  • Δ shared tables: +0
Exemplar 1 vs Exemplar 6
Decomposition B reduces the number of interfaces (IFN) by 0.75 and raises cohesion metrics (CHM +0.0907, CHD +0.0240, CMQ +0.4325) compared to A. However B increases inter‑service relationship count (IRN +37) and lowers service‑level quality (SMQ –0.2306) while also raising the data penalty (pen_data +0.9833), with no change in foreign‑key crossings or shared tables.
Interface count-0.7500
Msg cohesion+0.0907
Domain cohesion+0.0240
Inter-svc calls+37.0000
Structural MQ-0.2306
Conceptual MQ+0.4325
BC penalty-0.1746
NMI (BC align.)+0.3598
Data ownership+0.9833
  • Classes moved: 53
  • BCs fixed (A→B): —
  • BCs broken (A→B): —
  • Δ FK crossings: +0
  • Δ shared tables: +0
Exemplar 2 vs Exemplar 3
Interface count-1.4286
Msg cohesion+0.4690
Domain cohesion+0.3280
Inter-svc calls-57.0000
Structural MQ-0.1059
Conceptual MQ-0.1374
BC penalty+0.0911
NMI (BC align.)-0.2076
Data ownership-0.6417
  • Classes moved: 38
  • BCs fixed (A→B): —
  • BCs broken (A→B): —
  • Δ FK crossings: +0
  • Δ shared tables: +0
Exemplar 2 vs Exemplar 4
Interface count-1.4286
Msg cohesion+0.4690
Domain cohesion+0.3280
Inter-svc calls+11.0000
Structural MQ-0.0506
Conceptual MQ+0.0783
BC penalty+0.0009
NMI (BC align.)-0.0237
Data ownership-0.2083
  • Classes moved: 30
  • BCs fixed (A→B): —
  • BCs broken (A→B): —
  • Δ FK crossings: +0
  • Δ shared tables: +0
Exemplar 2 vs Exemplar 5
Interface count+0.2381
Msg cohesion+0.1007
Domain cohesion+0.0441
Inter-svc calls+9.0000
Structural MQ-0.2193
Conceptual MQ+0.3033
BC penalty-0.0860
NMI (BC align.)+0.0688
Data ownership-0.4917
  • Classes moved: 52
  • BCs fixed (A→B): —
  • BCs broken (A→B): —
  • Δ FK crossings: +0
  • Δ shared tables: +0
Exemplar 2 vs Exemplar 6
Interface count-0.1786
Msg cohesion+0.0776
Domain cohesion-0.0056
Inter-svc calls+57.0000
Structural MQ-0.1940
Conceptual MQ+0.3473
BC penalty-0.1487
NMI (BC align.)+0.1362
Data ownership+0.0917
  • Classes moved: 56
  • BCs fixed (A→B): —
  • BCs broken (A→B): —
  • Δ FK crossings: +0
  • Δ shared tables: +0
Exemplar 3 vs Exemplar 4
Decomposition B moves 46 classes and adds one more service (4 vs 3), which raises the IRN metric by 68 (worse) but improves SMQ (+0.055), CMQ (+0.216) and NMI_filtered (+0.184) while lowering the penalty_swm by 0.090. It also increases the pen_data penalty by 0.433 and leaves foreign‑key crossings, shared tables and other metrics unchanged.
Interface count+0.0000
Msg cohesion+0.0000
Domain cohesion+0.0000
Inter-svc calls+68.0000
Structural MQ+0.0554
Conceptual MQ+0.2157
BC penalty-0.0902
NMI (BC align.)+0.1839
Data ownership+0.4333
  • Classes moved: 46
  • BCs fixed (A→B): —
  • BCs broken (A→B): —
  • Δ FK crossings: +0
  • Δ shared tables: +0
Exemplar 3 vs Exemplar 5
Interface count+1.6667
Msg cohesion-0.3684
Domain cohesion-0.2839
Inter-svc calls+66.0000
Structural MQ-0.1134
Conceptual MQ+0.4407
BC penalty-0.1771
NMI (BC align.)+0.2764
Data ownership+0.1500
  • Classes moved: 53
  • BCs fixed (A→B): —
  • BCs broken (A→B): —
  • Δ FK crossings: +0
  • Δ shared tables: +0
Exemplar 3 vs Exemplar 6
B consolidates 65 classes into fewer services, which raises coupling metrics (IRN +114, IFN +1.25) and lowers cohesion (CHM -0.391, CHD -0.334) and service quality (SMQ -0.088). At the same time B improves modular quality (CMQ +0.485, NMI_filtered +0.344) and reduces service‑wire‑mesh penalty (-0.240) while keeping foreign‑key crossings and shared tables unchanged.
Interface count+1.2500
Msg cohesion-0.3915
Domain cohesion-0.3336
Inter-svc calls+114.0000
Structural MQ-0.0880
Conceptual MQ+0.4847
BC penalty-0.2398
NMI (BC align.)+0.3438
Data ownership+0.7333
  • Classes moved: 65
  • BCs fixed (A→B): —
  • BCs broken (A→B): —
  • Δ FK crossings: +0
  • Δ shared tables: +0
Exemplar 4 vs Exemplar 5
Interface count+1.6667
Msg cohesion-0.3684
Domain cohesion-0.2839
Inter-svc calls-2.0000
Structural MQ-0.1687
Conceptual MQ+0.2249
BC penalty-0.0870
NMI (BC align.)+0.0925
Data ownership-0.2833
  • Classes moved: 48
  • BCs fixed (A→B): —
  • BCs broken (A→B): —
  • Δ FK crossings: +0
  • Δ shared tables: +0
Exemplar 4 vs Exemplar 6
Decomposition B moves a total of 52 classes and expands the system from 4 to 6 services, yet it introduces no new foreign‑key crossings, shared tables, or broken bounded contexts. Compared with A, B incurs higher inter‑service foreign‑key count (IFN +1.25) and internal relationship number (IRN +46) and worsens cohesion, but it improves modularity quality (CMQ +0.269) and reduces the shared‑write‑model penalty (penalty_swm -0.1496).
Interface count+1.2500
Msg cohesion-0.3915
Domain cohesion-0.3336
Inter-svc calls+46.0000
Structural MQ-0.1434
Conceptual MQ+0.2690
BC penalty-0.1496
NMI (BC align.)+0.1599
Data ownership+0.3000
  • Classes moved: 52
  • 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.0231
Domain cohesion-0.0497
Inter-svc calls+48.0000
Structural MQ+0.0253
Conceptual MQ+0.0441
BC penalty-0.0626
NMI (BC align.)+0.0674
Data ownership+0.5833
  • Classes moved: 28
  • BCs fixed (A→B): —
  • BCs broken (A→B): —
  • Δ FK crossings: +0
  • Δ shared tables: +0