DECOMPASS

Daytrader

111
Pareto solutions
7
Exemplars
4 (α=0.5)
Clusters
0.46
HV ratio
0.472
Silhouette

Exemplars

#1#2#3#4#5#6#7
Exemplar 1: Fewest inter-service calls (cluster 2 medoid)
Cluster medoid cluster medoid
The proposed decomposition creates three services, with service 3 hosting the contained bounded contexts Market Data, Portfolio Management, and Trading, while the Account Management context is spread across services 1‑3. Cohesion metrics are moderate and there are no foreign‑key crossings.
3 services · Cluster 2 — fewest inter-service calls (n=17) · key: k3_mut0.5_cx0.3_s3_202605281714
Metrics
Interface count2.000
Msg cohesion0.355
Domain cohesion0.398
Inter-svc calls280.000
Structural MQ-0.825
Conceptual MQ0.051
BC penalty0.849
NMI (BC align.)0.095
Data ownership0.103
Verified facts
  • BCs contained: Market Data, Portfolio Management, Trading
  • BCs fragmented: Account Management
  • FK crossings between services: 0
  • Shared tables: ACCOUNTEJB, ACCOUNTPROFILEEJB, HOLDINGEJB, KEYGENEJB, ORDEREJB, QUOTEEJB
  • High-uncertainty classes: 7
Benefits
  • Contained bounded contexts have a majority share of 1.0, indicating strong cohesion within their service.
  • The cohesion metrics CHM (0.355) and CHD (0.398) reflect moderate internal cohesion of the resulting services.
  • Zero foreign‑key crossings (n_fk_crossings = 0) removes the need for distributed transactions across services.
Risks
  • Account Management is fragmented (status = "fragmented") across three services, which may increase inter‑service coupling.
  • Several classes have entropy_norm above the high‑uncertainty threshold of 0.6, indicating uncertainty in their bounded‑context assignment.
Services
TradeExecutionService: Executes trade actions and exposes trade‑related operations to clients.
TradePersistenceService: Handles direct persistence of trade records and key‑sequence generation for identifiers.
TradingDomainService [Account Management, Market Data, Portfolio Management, Trading]: Provides core trading capabilities including account management, portfolio holdings, market data streaming, order processing, and statistical reporting.
Services & data
Exemplar 2: Fewest inter-service calls (cluster 4 medoid)
Cluster medoid cluster medoid
The system is decomposed into five services, with two bounded contexts (Account Management and Portfolio Management) fully contained within a single service each. The Market Data and Trading contexts are fragmented across three services each, leading to a spread of classes among services 0, 1, and 4.
5 services · Cluster 4 — fewest inter-service calls (n=25) · key: 16_10_18_42_44_606429__mover_1
Metrics
Interface count2.667
Msg cohesion0.368
Domain cohesion0.287
Inter-svc calls108.000
Structural MQ0.141
Conceptual MQ0.391
BC penalty0.459
NMI (BC align.)0.379
Data ownership0.167
Verified facts
  • BCs contained: Account Management, Portfolio Management
  • BCs fragmented: Market Data, Trading
  • FK crossings between services: 0
  • Shared tables: ACCOUNTEJB, ACCOUNTPROFILEEJB, HOLDINGEJB, KEYGENEJB, ORDEREJB, QUOTEEJB
  • High-uncertainty classes: 7
Benefits
  • Zero foreign‑key crossings (n_fk_crossings = 0) eliminate the need for distributed transactions across services.
  • Containment of two contexts yields a majority share of 1.0, indicating strong cohesion within those services.
Risks
  • The fragmented Market Data and Trading contexts have majority shares below 0.5 (0.4286 and 0.6667 respectively), which may increase inter‑service coupling.
  • Seven classes have high uncertainty entropy (≥ 0.618), exceeding the threshold of 0.6, indicating ambiguous placement and potential cohesion issues.
Services
AccountTradingService [Account Management, Trading]: Manages customer accounts, processes trade orders, and executes trading operations.
PortfolioMarketDataService [Market Data, Portfolio Management]: Provides portfolio holdings, market summaries, and real‑time quote information for investment decisions.
TradingWebUiService: Serves web UI components for accounts, orders, portfolios, and market data.
HealthCheckService: Provides health‑check endpoints and diagnostics for the application.
BrokerStatisticsService: Handles broker message‑driven processing and aggregates trading statistics.
Services & data
Exemplar 3: Data-Optimal
Data-Optimal constraint anchor
['The proposed decomposition maps each contained bounded context—Account Management, Portfolio Management, and Trading—to its own microservice, while the fragmented Market Data context would need to be split across two services (service 3 and service 5).', 'The overall system has five services, no foreign‑key crossings, and a moderate cohesion metric (CHM = 0.401) indicating reasonable internal cohesion within the proposed services.']
5 services · Cluster 4 — fewest inter-service calls (n=25) · key: 16_10_18_44_26_307330__unir_0
Metrics
Interface count3.000
Msg cohesion0.401
Domain cohesion0.377
Inter-svc calls45.000
Structural MQ0.203
Conceptual MQ0.553
BC penalty0.507
NMI (BC align.)0.327
Data ownership0.011
Verified facts
  • BCs contained: Account Management, Portfolio Management, Trading
  • BCs fragmented: Market Data
  • FK crossings between services: 0
  • Shared tables: QUOTEEJB
  • High-uncertainty classes: 7
Benefits
  • Contained bounded contexts have a majority share of 1.0 (Account Management) and 0.8333 (Trading), exceeding the bc_contained_share threshold of 0.8, which reduces coupling between services.
  • Zero foreign‑key crossings (n_fk_crossings = 0) eliminates the need for distributed transactions across services.
Risks
  • Market Data is fragmented across two services (service 3 holds 5 classes, service 5 holds 2), which may increase inter‑service communication.
  • Several classes have high uncertainty entropy above the high_uncertainty_entropy threshold of 0.6 (e.g., TradeSLSBRemote entropy 0.8419), indicating ambiguous placement and potential cohesion issues.
  • The shared table QUOTEEJB is accessed by multiple services, which could introduce data‑consistency challenges despite no foreign‑key crossings.
Services
PingHealthService: Provides health‑check endpoints and EJB ping functionality for system monitoring.
PortfolioHoldingService [Portfolio Management]: Manages portfolio holding data and performs financial utility calculations.
TradingUiDataService: Supplies JSF‑backed data models for accounts, orders, quotes, and market summaries to the web UI.
TradingExecutionService [Account Management, Market Data, Trading]: Handles account management, order processing, market data streaming, and trade execution.
MarketSummaryService: Provides aggregated market summary information and maintains a singleton cache of the data.
Services & data
Exemplar 4: Best data ownership (cluster 3 medoid)
Cluster medoid cluster medoid
The candidate splits the monolith into four microservices aligned with the identified bounded contexts: Trading, Portfolio Management, Account Management, and Market Data. Two contexts (Trading, Portfolio Management) are contained with high majority share (0.8333 and 1.0) and low cross‑service coupling, while Account Management and Market Data are fragmented with lower majority shares (0.6 and 0.2857).
12 services · Cluster 3 — best data ownership (n=17) · key: run39_eps0.85_step0.025_ms5__mover_1
Metrics
Interface count1.750
Msg cohesion0.441
Domain cohesion0.466
Inter-svc calls428.000
Structural MQ-0.718
Conceptual MQ0.860
BC penalty0.651
NMI (BC align.)0.493
Data ownership0.067
Verified facts
  • BCs contained: Portfolio Management, Trading
  • BCs fragmented: Account Management, Market Data
  • FK crossings between services: 0
  • Shared tables: ACCOUNTEJB, ACCOUNTPROFILEEJB, HOLDINGEJB, KEYGENEJB, ORDEREJB, QUOTEEJB
  • High-uncertainty classes: 7
Benefits
  • Contained contexts exhibit high intra‑service cohesion, reflected by majority_share >0.8 and status "contained".
  • Zero foreign‑key crossings (n_fk_crossings = 0) reduces the need for distributed transactions.
  • Overall domain modularity is strong (CMQ = 0.86) and cohesion moderate (CHM = 0.44), supporting independent deployment.
Risks
  • Fragmented contexts have low majority_share (<0.8) indicating higher coupling across services.
  • Several classes have entropy_norm above the high_uncertainty_entropy threshold (0.6), creating ambiguity in service boundaries.
  • Negative SMQ (-0.718) suggests potential service modularity quality concerns.
Services
AccountTradingService [Account Management, Trading]: Manages customer accounts, holdings, orders and executes trade actions.
MarketSummaryService: Provides up‑to‑date market summary information.
KeySequenceService: Generates and supplies unique key sequences for entity identifiers.
BrokerMessageService: Handles broker‑related asynchronous messages via MDB.
StreamerMessageService: Processes streaming messages for market data distribution.
MarketDataService [Market Data]: Delivers market data and quote information to consumers.
+6 more services
OrderCompletionService: Finalizes and persists completed orders in a background thread.
PortfolioUtilityService [Portfolio Management]: Provides financial calculation utilities for portfolio management.
KeyBlockService: Manages allocation and recycling of key blocks.
LoggingService: Centralizes application logging and log retrieval.
MessageStatsService: Collects and reports statistics for message‑driven beans.
TimerStatisticsService: Tracks and reports timer‑based performance metrics.
Services & data
Exemplar 5: BC-Optimal
BC-Optimal constraint anchor
The candidate decomposition groups services by the four identified bounded contexts, keeping the contained Portfolio Management as a single microservice and consolidating the fragmented Account Management, Market Data, and Trading contexts into separate microservices. This results in 4 microservices covering 21 existing services, with the majority share of services per context ranging from 0.2 to 1.0.
21 services · Cluster 1 — fewest interfaces (n=52) · key: run10_eps0.55_step0.025_ms2__mover_0
Metrics
Interface count1.167
Msg cohesion0.427
Domain cohesion0.456
Inter-svc calls614.000
Structural MQ-1.063
Conceptual MQ0.967
BC penalty0.498
NMI (BC align.)0.591
Data ownership0.590
Verified facts
  • BCs contained: Portfolio Management
  • BCs fragmented: Account Management, Market Data, Trading
  • FK crossings between services: 0
  • Shared tables: ACCOUNTEJB, ACCOUNTPROFILEEJB, HOLDINGEJB, KEYGENEJB, ORDEREJB, QUOTEEJB
  • High-uncertainty classes: 7
Benefits
  • Aligning services with their bounded contexts improves internal cohesion, as indicated by the CHM metric of 0.4268.
  • The decomposition introduces no foreign key crossing transactions because n_fk_crossings is 0.
  • Consolidating fragmented contexts reduces the penalty for service‑world‑model mismatch, reflected by a penalty_swm of 0.4978.
Risks
  • Fragmented contexts have low majority shares (e.g., Account Management 0.2, Market Data 0.1429), which may increase inter‑service communication and distributed transaction overhead, as suggested by the high IRN of 614.
  • Several classes have high uncertainty entropy (entropy_norm > 0.6), indicating ambiguous placement and risk of mis‑assignment to bounded contexts.
  • The SMQ metric is negative (-1.0635), signaling potential service modularity quality issues that could arise after decomposition.
Services
TradeExecutionService [Trading]: Executes trade actions and coordinates local and remote trade session beans.
MarketSummaryService [Market Data]: Provides aggregated market summary data to clients.
RuntimeStatsService: Collects and exposes application runtime statistics.
KeySequenceService: Generates sequential keys for entity identifiers.
TradeAccountService [Account Management]: Manages trade operations tied to user accounts.
BrokerMessageService: Handles broker‑related asynchronous messages via MDB.
+15 more services
StreamerMessageService: Processes streaming market data messages using MDB.
MarketSummaryCache: Caches the latest market summary for fast access.
TradeProcessingService: Processes individual trade requests through a stateless bean.
AccountInfoService: Retrieves and updates basic account information.
AccountProfileService: Manages detailed profile data for user accounts.
HoldingManagementService: Tracks holdings and positions for each account.
OrderManagementService: Handles creation, update, and lifecycle of trade orders.
QuoteService: Provides real‑time price quotes for securities.
OrderCompletionService: Executes background processing to finalize completed orders.
PortfolioAnalyticsService [Portfolio Management]: Performs financial calculations and analytics for portfolios.
KeyBlockService: Manages blocks of pre‑allocated keys for efficient ID generation.
LoggingService: Centralizes application logging and log retrieval.
MessagingStatsService: Collects statistics from message‑driven beans.
TimerStatisticsService: Tracks timing metrics for scheduled tasks and timers.
TradeConfigurationService: Manages and provides access to trading system configuration parameters and settings.
Services & data
Exemplar 6: Structural-Best · Compromise
Structural-Best · Compromise constraint anchor
The candidate decomposition maps each bounded context to a microservice, yielding four services; Portfolio Management is fully contained within a single service, while Account Management, Market Data, and Trading are fragmented across multiple services.
20 services · Cluster 1 — fewest interfaces (n=52) · key: run10_eps0.55_step0.025_ms2__unir_0
Metrics
Interface count1.400
Msg cohesion0.508
Domain cohesion0.540
Inter-svc calls594.000
Structural MQ-1.351
Conceptual MQ0.959
BC penalty0.529
NMI (BC align.)0.504
Data ownership0.084
Verified facts
  • BCs contained: Portfolio Management
  • BCs fragmented: Account Management, Market Data, Trading
  • FK crossings between services: 0
  • Shared tables: ACCOUNTEJB, ACCOUNTPROFILEEJB, HOLDINGEJB, KEYGENEJB, ORDEREJB, QUOTEEJB
  • High-uncertainty classes: 7
Benefits
  • Portfolio Management achieves full containment with a majority share of 1.0 in service 15.
  • The decomposition benefits from zero foreign key crossings, eliminating distributed transaction coordination.
  • Cohesion metrics CHM (0.508) and CHD (0.540) indicate moderate internal cohesion across the system.
Risks
  • Fragmented bounded contexts have classes spread over multiple services, which can increase inter‑service communication overhead.
  • Several classes exhibit high uncertainty entropy above the 0.6 threshold, e.g., TradeSLSBRemote (0.842) and TradeSLSBLocal (0.840), making their placement ambiguous.
  • Shared database tables such as ACCOUNTEJB and QUOTEEJB are accessed by multiple services, introducing data coupling.
Services
MarketDataService [Market Data]: Provides aggregated market summary information for clients.
StatisticsService: Collects and exposes runtime performance statistics of the trading platform.
AccountKeyService [Account Management]: Generates and manages sequential keys for account entities.
TradeExecutionService: Executes trade orders directly against the market.
TradeProcessingService [Trading]: Coordinates trade actions, broker communication, and provides trade services to clients.
MarketStreamService: Streams real-time market data to subscribed components.
+14 more services
MarketSummaryCacheService: Caches and provides the latest market summary to callers.
TradeBusinessService: Implements business logic for trade operations.
AccountDataService: Manages persistence and retrieval of account information.
AccountProfileService: Handles account profile details and preferences.
HoldingManagementService: Manages holdings data for customer portfolios.
OrderManagementService: Persists and retrieves trade order information.
QuoteService: Provides latest price quotes for securities.
OrderCompletionService: Processes and finalizes pending orders asynchronously.
PortfolioAnalyticsService [Portfolio Management]: Performs financial calculations and analytics for portfolios.
KeyManagementService: Manages blocks of keys for entity identification.
LoggingService: Centralizes application logging and log retrieval.
MessagingStatsService: Collects statistics from message-driven bean components.
TimerMetricsService: Tracks and reports timer-based performance metrics.
TradeConfigurationService: Provides configuration settings for trade processing.
Services & data
Exemplar 7: Fewest interfaces (cluster 1 medoid)
Cluster medoid cluster medoid
['The proposed decomposition isolates the contained ‘Portfolio Management’ bounded context as a single microservice while keeping the fragmented ‘Account Management’, ‘Market Data’, and ‘Trading’ contexts distributed across their existing services.', 'Overall class cohesion is moderate (CHM = 0.44, CHD = 0.44) and class modularity quality is high (CMQ = 0.97), but service modularity quality is low (SMQ = -0.91), indicating that the current service boundaries are not well aligned with domain boundaries.']
20 services · Cluster 1 — fewest interfaces (n=52) · key: run33_eps0.75_step0.05_ms5__mover_0
Metrics
Interface count1.400
Msg cohesion0.444
Domain cohesion0.439
Inter-svc calls594.000
Structural MQ-0.912
Conceptual MQ0.966
BC penalty0.515
NMI (BC align.)0.555
Data ownership0.337
Verified facts
  • BCs contained: Portfolio Management
  • BCs fragmented: Account Management, Market Data, Trading
  • FK crossings between services: 0
  • Shared tables: ACCOUNTEJB, ACCOUNTPROFILEEJB, HOLDINGEJB, KEYGENEJB, ORDEREJB, QUOTEEJB
  • High-uncertainty classes: 7
Benefits
  • Because there are zero foreign‑key crossings (n_fk_crossings = 0), the decomposition avoids distributed transactions across services.
  • The ‘Portfolio Management’ context already has a single service with 100 % majority share, giving it perfect containment and high cohesion.
  • High class modularity quality (CMQ = 0.97) suggests that classes within each bounded context are well grouped, facilitating independent deployment.
Risks
  • The fragmented contexts have low majority share (e.g., Trading majority_share = 0.5) and spread across multiple services, which may increase inter‑service coupling and operational overhead.
  • Negative service modularity quality (SMQ = -0.91) indicates that current service boundaries may cut across domain concepts, risking cohesion loss when refactored.
  • High inter‑service relational number (IRN = 594) suggests many implicit dependencies that could become runtime coupling after decomposition.
Services
TradeExecutionService [Trading]: Executes trade actions and provides trade services to clients.
MarketSummaryService [Market Data]: Provides aggregated market summary data to consumers.
RuntimeStatsService: Collects and exposes application run statistics.
KeySequenceService: Generates sequential keys for entity identifiers.
TradeAccountService [Account Management]: Handles trade operations linked to user accounts.
BrokerMessageService: Processes broker messages for trade execution via a message‑driven bean.
+14 more services
MarketStreamerService: Streams real‑time market data updates using a message‑driven bean.
MarketSummaryCacheService: Caches and serves a singleton market summary to reduce recomputation.
AccountInfoService: Manages basic account data retrieval and updates.
AccountProfileService: Handles detailed profile information for user accounts.
HoldingManagementService: Manages holdings data for investment portfolios.
OrderManagementService: Processes, stores, and tracks order information.
QuoteDataService: Provides real‑time quote data for securities.
OrderCompletionService: Executes order completion logic asynchronously.
PortfolioAnalyticsService [Portfolio Management]: Performs financial calculations and analytics for portfolio management.
KeyBlockService: Manages blocks of generated keys for batch allocation.
ApplicationLoggingService: Centralizes logging operations across the application.
MDBStatsService: Tracks statistics of message‑driven bean activity.
TimerStatisticsService: Records timing metrics for scheduled tasks.
TradeConfigurationService: Provides configuration settings for trading operations.
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.0127
Domain cohesion-0.1105
Inter-svc calls-172.0000
Structural MQ+0.9660
Conceptual MQ+0.3404
BC penalty-0.3901
NMI (BC align.)+0.2842
Data ownership+0.0632
  • Classes moved: 13
  • BCs fixed (A→B): Account Management
  • BCs broken (A→B): Market Data, Trading
  • Δ FK crossings: +0
  • Δ shared tables: +0
Exemplar 1 vs Exemplar 3
Interface count+1.0000
Msg cohesion+0.0461
Domain cohesion-0.0207
Inter-svc calls-235.0000
Structural MQ+1.0287
Conceptual MQ+0.5026
BC penalty-0.3429
NMI (BC align.)+0.2319
Data ownership-0.0920
  • Classes moved: 8
  • BCs fixed (A→B): Account Management
  • BCs broken (A→B): Market Data
  • Δ FK crossings: +0
  • Δ shared tables: -5
Exemplar 1 vs Exemplar 4
Interface count-0.2500
Msg cohesion+0.0858
Domain cohesion+0.0690
Inter-svc calls+148.0000
Structural MQ+0.1074
Conceptual MQ+0.8094
BC penalty-0.1983
NMI (BC align.)+0.3987
Data ownership-0.0369
  • Classes moved: 14
  • BCs fixed (A→B): —
  • BCs broken (A→B): Market Data
  • Δ FK crossings: +0
  • Δ shared tables: +0
Exemplar 1 vs Exemplar 5
Interface count-0.8333
Msg cohesion+0.0718
Domain cohesion+0.0586
Inter-svc calls+334.0000
Structural MQ-0.2383
Conceptual MQ+0.9166
BC penalty-0.3516
NMI (BC align.)+0.4963
Data ownership+0.4866
  • Classes moved: 20
  • BCs fixed (A→B): —
  • BCs broken (A→B): Market Data, Trading
  • Δ FK crossings: +0
  • Δ shared tables: +0
Exemplar 1 vs Exemplar 6
Interface count-0.6000
Msg cohesion+0.1531
Domain cohesion+0.1422
Inter-svc calls+314.0000
Structural MQ-0.5262
Conceptual MQ+0.9082
BC penalty-0.3203
NMI (BC align.)+0.4095
Data ownership-0.0199
  • Classes moved: 20
  • BCs fixed (A→B): —
  • BCs broken (A→B): Market Data, Trading
  • Δ FK crossings: +0
  • Δ shared tables: +0
Exemplar 1 vs Exemplar 7
Interface count-0.6000
Msg cohesion+0.0887
Domain cohesion+0.0418
Inter-svc calls+314.0000
Structural MQ-0.0871
Conceptual MQ+0.9149
BC penalty-0.3341
NMI (BC align.)+0.4601
Data ownership+0.2332
  • Classes moved: 20
  • BCs fixed (A→B): —
  • BCs broken (A→B): Market Data, Trading
  • Δ FK crossings: +0
  • Δ shared tables: +0
Exemplar 2 vs Exemplar 3
Interface count+0.3333
Msg cohesion+0.0334
Domain cohesion+0.0898
Inter-svc calls-63.0000
Structural MQ+0.0627
Conceptual MQ+0.1622
BC penalty+0.0472
NMI (BC align.)-0.0523
Data ownership-0.1552
  • Classes moved: 8
  • BCs fixed (A→B): Trading
  • BCs broken (A→B): —
  • Δ FK crossings: +0
  • Δ shared tables: -5
Exemplar 2 vs Exemplar 4
Interface count-0.9167
Msg cohesion+0.0731
Domain cohesion+0.1794
Inter-svc calls+320.0000
Structural MQ-0.8586
Conceptual MQ+0.4690
BC penalty+0.1919
NMI (BC align.)+0.1145
Data ownership-0.1001
  • Classes moved: 10
  • BCs fixed (A→B): Trading
  • BCs broken (A→B): Account Management
  • Δ FK crossings: +0
  • Δ shared tables: +0
Exemplar 2 vs Exemplar 5
Interface count-1.5000
Msg cohesion+0.0591
Domain cohesion+0.1690
Inter-svc calls+506.0000
Structural MQ-1.2043
Conceptual MQ+0.5762
BC penalty+0.0385
NMI (BC align.)+0.2122
Data ownership+0.4233
  • Classes moved: 19
  • BCs fixed (A→B): —
  • BCs broken (A→B): Account Management
  • Δ FK crossings: +0
  • Δ shared tables: +0
Exemplar 2 vs Exemplar 6
Interface count-1.2667
Msg cohesion+0.1404
Domain cohesion+0.2527
Inter-svc calls+486.0000
Structural MQ-1.4922
Conceptual MQ+0.5678
BC penalty+0.0698
NMI (BC align.)+0.1253
Data ownership-0.0831
  • Classes moved: 18
  • BCs fixed (A→B): —
  • BCs broken (A→B): Account Management
  • Δ FK crossings: +0
  • Δ shared tables: +0
Exemplar 2 vs Exemplar 7
Interface count-1.2667
Msg cohesion+0.0759
Domain cohesion+0.1523
Inter-svc calls+486.0000
Structural MQ-1.0531
Conceptual MQ+0.5745
BC penalty+0.0560
NMI (BC align.)+0.1760
Data ownership+0.1700
  • Classes moved: 18
  • BCs fixed (A→B): —
  • BCs broken (A→B): Account Management
  • Δ FK crossings: +0
  • Δ shared tables: +0
Exemplar 3 vs Exemplar 4
Interface count-1.2500
Msg cohesion+0.0397
Domain cohesion+0.0897
Inter-svc calls+383.0000
Structural MQ-0.9213
Conceptual MQ+0.3069
BC penalty+0.1447
NMI (BC align.)+0.1668
Data ownership+0.0551
  • Classes moved: 10
  • BCs fixed (A→B): —
  • BCs broken (A→B): Account Management
  • Δ FK crossings: +0
  • Δ shared tables: +5
Exemplar 3 vs Exemplar 5
Decomposition B moves 18 classes into different services, increasing the number of services from 3 to 5 and breaking the Account Management and Trading bounded contexts. It improves cohesion (CHM +0.02573, CHD +0.079257) and reduces interface count (IFN -1.833) while lowering penalty (penalty_swm -0.0087) and raising NMI (0.264), but it raises inter‑service relational noise (IRN +569), degrades service modular quality (SMQ -1.267), adds 5 shared tables, and increases penalty data (+0.579).
Interface count-1.8333
Msg cohesion+0.0257
Domain cohesion+0.0793
Inter-svc calls+569.0000
Structural MQ-1.2670
Conceptual MQ+0.4140
BC penalty-0.0087
NMI (BC align.)+0.2644
Data ownership+0.5785
  • Classes moved: 18
  • BCs fixed (A→B): —
  • BCs broken (A→B): Account Management, Trading
  • Δ FK crossings: +0
  • Δ shared tables: +5
Exemplar 3 vs Exemplar 6
B moves 16 classes, breaks the Account Management and Trading bounded contexts, and adds 5 shared tables, increasing coupling. It improves cohesion (CHM +0.107, CHD +0.163) and modularity (CMQ +0.406, NMI +0.178) while lowering interface count (IFN -1.6) but worsens inter‑service remote calls (IRN +549), service quality (SMQ -1.555) and penalty metrics.
Interface count-1.6000
Msg cohesion+0.1070
Domain cohesion+0.1629
Inter-svc calls+549.0000
Structural MQ-1.5549
Conceptual MQ+0.4057
BC penalty+0.0226
NMI (BC align.)+0.1776
Data ownership+0.0721
  • Classes moved: 16
  • BCs fixed (A→B): —
  • BCs broken (A→B): Account Management, Trading
  • Δ FK crossings: +0
  • Δ shared tables: +5
Exemplar 3 vs Exemplar 7
Interface count-1.6000
Msg cohesion+0.0426
Domain cohesion+0.0625
Inter-svc calls+549.0000
Structural MQ-1.1158
Conceptual MQ+0.4124
BC penalty+0.0089
NMI (BC align.)+0.2282
Data ownership+0.3252
  • Classes moved: 17
  • BCs fixed (A→B): —
  • BCs broken (A→B): Account Management, Trading
  • Δ FK crossings: +0
  • Δ shared tables: +5
Exemplar 4 vs Exemplar 5
Interface count-0.5833
Msg cohesion-0.0140
Domain cohesion-0.0104
Inter-svc calls+186.0000
Structural MQ-0.3457
Conceptual MQ+0.1071
BC penalty-0.1534
NMI (BC align.)+0.0976
Data ownership+0.5234
  • Classes moved: 10
  • BCs fixed (A→B): —
  • BCs broken (A→B): Trading
  • Δ FK crossings: +0
  • Δ shared tables: +0
Exemplar 4 vs Exemplar 6
Interface count-0.3500
Msg cohesion+0.0673
Domain cohesion+0.0732
Inter-svc calls+166.0000
Structural MQ-0.6336
Conceptual MQ+0.0988
BC penalty-0.1221
NMI (BC align.)+0.0108
Data ownership+0.0170
  • Classes moved: 10
  • BCs fixed (A→B): —
  • BCs broken (A→B): Trading
  • Δ FK crossings: +0
  • Δ shared tables: +0
Exemplar 4 vs Exemplar 7
Interface count-0.3500
Msg cohesion+0.0028
Domain cohesion-0.0271
Inter-svc calls+166.0000
Structural MQ-0.1945
Conceptual MQ+0.1055
BC penalty-0.1358
NMI (BC align.)+0.0615
Data ownership+0.2701
  • Classes moved: 9
  • BCs fixed (A→B): —
  • BCs broken (A→B): Trading
  • Δ FK crossings: +0
  • Δ shared tables: +0
Exemplar 5 vs Exemplar 6
B moves the TradeServices class from service 4 to service 5, increasing cohesion (CHM +0.081, CHD +0.084) and reducing inter‑service invocations (IRN –20) while keeping foreign‑key crossings and shared tables unchanged. However B worsens interface count (IFN +0.233), shared‑query quality (SMQ –0.288), shared‑command quality (CMQ –0.008), and penalty_swm (+0.031), and lowers NMI_filtered (–0.087) though it improves pen_data (–0.506).
Interface count+0.2333
Msg cohesion+0.0813
Domain cohesion+0.0836
Inter-svc calls-20.0000
Structural MQ-0.2880
Conceptual MQ-0.0083
BC penalty+0.0313
NMI (BC align.)-0.0869
Data ownership-0.5064
  • Classes moved: 2
  • BCs fixed (A→B): —
  • BCs broken (A→B): —
  • Δ FK crossings: +0
  • Δ shared tables: +0
Exemplar 5 vs Exemplar 7
Interface count+0.2333
Msg cohesion+0.0168
Domain cohesion-0.0167
Inter-svc calls-20.0000
Structural MQ+0.1512
Conceptual MQ-0.0016
BC penalty+0.0176
NMI (BC align.)-0.0362
Data ownership-0.2533
  • Classes moved: 2
  • BCs fixed (A→B): —
  • BCs broken (A→B): —
  • Δ FK crossings: +0
  • Δ shared tables: +0
Exemplar 6 vs Exemplar 7
Interface count+0.0000
Msg cohesion-0.0644
Domain cohesion-0.1004
Inter-svc calls+0.0000
Structural MQ+0.4392
Conceptual MQ+0.0067
BC penalty-0.0138
NMI (BC align.)+0.0507
Data ownership+0.2531
  • Classes moved: 2
  • BCs fixed (A→B): —
  • BCs broken (A→B): —
  • Δ FK crossings: +0
  • Δ shared tables: +0