DECOMPASS

PetClinic

31
Pareto solutions
5
Exemplars
4 (α=0.5)
Clusters
0.65
HV ratio
0.537
Silhouette

Canonical reference (S*)

Canonical reference (S*)
— canonical reference (S*)
spring-petclinic/spring-petclinic-microservices (GitHub) — coincide con la referencia ASE 2024
3 services · key: sstar_petclinic_primario
Metrics
Interface count2.333
Msg cohesion0.354
Domain cohesion0.544
Inter-svc calls5.000
Structural MQ0.285
Conceptual MQ0.152
BC penalty0.782
NMI (BC align.)0.205
Data ownership0.000
Verified facts
  • BCs contained: —
  • BCs fragmented: —
  • FK crossings between services: 0
  • Shared tables: OWNERS
  • High-uncertainty classes: 0
Benefits
    Risks
      Services
      customers-service:
      vets-service:
      visits-service:
      Services & data

      Exemplars

      #1#2#3#4#5
      Exemplar 1: Fewest interfaces (cluster 1 medoid)
      Cluster medoid cluster medoid
      The proposed decomposition isolates the Visits bounded context as a single microservice (service 3) because it is contained and has a majority share of 1.0. The Customers and Vets bounded contexts are fragmented across multiple services, which would require additional coordination.
      6 services · Cluster 1 — fewest interfaces (n=2) · key: 16_10_18_49_16_274545
      Metrics
      Interface count1.750
      Msg cohesion0.355
      Domain cohesion0.556
      Inter-svc calls22.000
      Structural MQ0.169
      Conceptual MQ0.602
      BC penalty0.712
      NMI (BC align.)0.231
      Data ownership0.000
      Verified facts
      • BCs contained: Visits
      • BCs fragmented: Customers, Vets
      • FK crossings between services: 0
      • Shared tables: OWNERS
      • High-uncertainty classes: 10
      Benefits
      • Visits microservice enjoys full cohesion with all its classes in one service, reducing inter‑service calls.
      • No foreign key crossings exist and shared tables are limited to OWNERS, minimizing distributed transaction risk.
      • Cohesion metrics CHM 0.355 and CHD 0.555 indicate moderate internal cohesion across the overall system.
      Risks
      • Fragmented Customers and Vets contexts spread across 6 services increase coupling and may lead to higher latency.
      • High uncertainty entropy for several classes exceeds the threshold of 0.6, indicating ambiguous placement.
      • The shared table OWNERS could become a source of contention if accessed by multiple microservices.
      Services
      OwnerManagementService: Handles CRUD operations and business rules for pet owners.
      SpecialtyCatalogService: Provides lookup and maintenance of veterinary specialties.
      PetCustomerManagement [Customers]: Manages pet entities, types, and validation for customer-owned animals.
      VisitManagementService [Visits]: Records and retrieves veterinary visit information for pets.
      VetManagementService [Vets]: Maintains vet profiles, schedules, and related data.
      PersonIdentityService: Stores and provides basic personal information used across the system.
      Services & data
      Exemplar 2: Highest message cohesion (cluster 2 medoid)
      Cluster medoid cluster medoid
      The proposed decomposition aligns three microservices with the identified bounded contexts: Customers, Vets, and Visits. Overall class cohesion is high (CHD 0.794) while the average inter‑service foreign‑key count is modest (IFN 2.33).
      5 services · Cluster 2 — highest message cohesion (n=3) · key: 16_10_18_48_43_706023__mover_1
      Metrics
      Interface count2.333
      Msg cohesion0.580
      Domain cohesion0.794
      Inter-svc calls3.000
      Structural MQ0.237
      Conceptual MQ0.317
      BC penalty0.716
      NMI (BC align.)0.579
      Data ownership0.000
      Verified facts
      • BCs contained: Visits
      • BCs fragmented: Customers, Vets
      • FK crossings between services: 0
      • Shared tables: TYPES
      • High-uncertainty classes: 10
      Benefits
      • Visits is a contained bounded context (majority_share 1.0) which can be deployed as an independent service with minimal cross‑service coupling.
      • No foreign‑key crossings are present (n_fk_crossings 0), reducing the need for distributed transactions.
      Risks
      • Customers and Vets are fragmented (status "fragmented") with classes spread across multiple services (majority_share 0.4615 and 0.75), which may increase coordination overhead.
      • Several classes have high uncertainty entropy (>0.6), exceeding the threshold (0.6), indicating ambiguous placement and potential refactoring.
      • The shared table TYPES is accessed by multiple services, introducing a shared data coupling point.
      Services
      SpecialtyCatalogService: Maintains the catalog of veterinary specialties and provides lookup functionality for other services.
      PetTypeCatalogService: Manages pet type definitions, including persistence and formatting for display purposes.
      PersonCoreService: Provides shared person‑related entities such as base person data and common vet references for the domain.
      VetManagementService [Vets]: Handles creation, retrieval, and maintenance of veterinarian records within the clinic.
      OwnerPetVisitService [Customers, Visits]: Coordinates owner information, pet records, and visit scheduling to support customer interactions with the clinic.
      Services & data
      Exemplar 3: Fewest interfaces (cluster 4 medoid)
      Cluster medoid cluster medoid
      The system is decomposed into three bounded contexts: Customers, Vets, and Visits. Customers and Visits are marked as contained, while Vets is fragmented.
      7 services · Cluster 4 — fewest interfaces (n=17) · key: run39_eps0.85_step0.025_ms5__mover_0
      Metrics
      Interface count1.750
      Msg cohesion0.532
      Domain cohesion0.658
      Inter-svc calls16.000
      Structural MQ-0.030
      Conceptual MQ0.727
      BC penalty0.671
      NMI (BC align.)0.734
      Data ownership0.000
      Verified facts
      • BCs contained: Customers, Visits
      • BCs fragmented: Vets
      • FK crossings between services: 0
      • Shared tables: OWNERS, TYPES, VETS
      • High-uncertainty classes: 10
      Benefits
      • Customers context spans 13 classes across 3 services with a majority share of 84.62%, indicating strong internal cohesion.
      • The overall system has zero foreign‑key crossings (n_fk_crossings = 0), reducing the need for distributed transactions.
      • Cohesion metric CHD is 0.658, reflecting relatively high cohesion within the decomposition.
      Risks
      • Vets context is fragmented across 4 services with a majority share of only 0.25, suggesting possible cohesion and coupling challenges.
      • Class Vets shows high entropy (0.9077) and low confidence (0.4731) in its bounded‑context assignment, indicating uncertainty.
      Services
      ClinicCoreService [Customers, Vets]: Manages owners, pets, vets, specialties, and pet types within the clinic.
      PetTypeFormattingService: Formats pet type data for presentation layers.
      PetValidationService: Validates pet entity data before persistence.
      VisitManagementService [Visits]: Handles creation and retrieval of clinic visit records.
      VetEndpointService: Exposes API endpoints for vet operations.
      VetPersistenceService: Provides data access for vet entities.
      +1 more service
      VetCatalogService: Manages the catalog of vets and their specialties.
      Services & data
      Exemplar 4: BC-Optimal
      BC-Optimal constraint anchor
      The system is split into four services, grouping classes primarily by the Customers, Vets, and Visits bounded contexts. Customers is contained within a single service (service 0) with 13 classes, while Vets and Visits are fragmented across two services each.
      4 services · Cluster 3 — BC-Optimal (n=9) · key: run41_eps0.85_step0.05_ms3__mover_2
      Metrics
      Interface count3.500
      Msg cohesion0.366
      Domain cohesion0.692
      Inter-svc calls4.000
      Structural MQ0.104
      Conceptual MQ0.673
      BC penalty0.740
      NMI (BC align.)0.797
      Data ownership0.000
      Verified facts
      • BCs contained: Customers
      • BCs fragmented: Vets, Visits
      • FK crossings between services: 0
      • Shared tables: —
      • High-uncertainty classes: 10
      Benefits
      • The contained Customers context eliminates foreign‑key crossings, resulting in zero cross‑service transactions.
      • Customers shows a high majority share of 0.8462, indicating strong cohesion within its service.
      • Vets and Visits each have a clear majority service (share 0.75 and 0.5), providing defined ownership despite being fragmented.
      Risks
      • The fragmented Vets and Visits contexts may increase inter‑service communication and coordination overhead.
      • Several classes have entropy_norm above the high‑uncertainty threshold of 0.6, indicating uncertain placement that could lead to coupling issues.
      • The SMQ metric is low (0.104), suggesting limited service modularity quality which may affect maintainability.
      Services
      CustomerVisitService [Customers, Visits]: Manages owners, pets, pet types and schedules customer visits.
      VeterinaryStaffService [Vets]: Handles vet records, specialties and related operations.
      PetValidationService: Validates pet data before it is persisted or processed.
      VisitManagementService: Provides CRUD operations for visit (appointment) entities.
      Services & data
      Exemplar 5: Structural-Best · Compromise
      Structural-Best · Compromise constraint anchor
      The proposed decomposition splits the PetClinic monolith into five services, distributing the 13 classes of the Customers context across four services, the 4 classes of Vets across two services, and the 2 classes of Visits across two services. All three identified bounded contexts are marked as fragmented, and there are no foreign‑key crossings between services.
      5 services · Cluster 4 — fewest interfaces (n=17) · key: run28_eps0.75_step0.025_ms2__mover_1
      Metrics
      Interface count2.333
      Msg cohesion0.580
      Domain cohesion0.794
      Inter-svc calls7.000
      Structural MQ0.180
      Conceptual MQ0.723
      BC penalty0.711
      NMI (BC align.)0.709
      Data ownership0.000
      Verified facts
      • BCs contained: —
      • BCs fragmented: Customers, Vets, Visits
      • FK crossings between services: 0
      • Shared tables: TYPES
      • High-uncertainty classes: 10
      Benefits
      • Each service contains a clear majority of classes from a single bounded context (majority_share 0.7692 for Customers, 0.75 for Vets, 0.5 for Visits), supporting higher intra‑service cohesion.
      • The absence of foreign‑key crossings (n_fk_crossings = 0) eliminates the need for distributed transactions across services.
      • The overall class‑level cohesion metric (CHM) is 0.5798, reflecting reasonable cohesion within the services.
      Risks
      • All bounded contexts are fragmented, which may increase coordination overhead when implementing cross‑context use cases.
      • Several classes have high entropy (e.g., Vets with 0.9077 and Vet with 0.8971) exceeding the high‑uncertainty threshold of 0.6, indicating uncertainty in their correct placement.
      • The shared table TYPES is accessed by multiple services, potentially creating hidden coupling despite no foreign‑key crossings.
      Services
      CustomerVisitService [Customers, Visits]: Manages owners, their pets, and the scheduling and recording of visits.
      VeterinarianManagementService [Vets]: Handles creation, retrieval, and maintenance of veterinarian records.
      PetTypeCatalogService: Provides CRUD operations and formatting for pet type definitions.
      PetValidationService: Validates pet data against business rules before persistence.
      VisitManagementService: Coordinates visit scheduling, updates, and storage for pet appointments.
      Services & data

      Pairwise comparisons

      1↔21↔31↔41↔52↔32↔42↔53↔43↔54↔5
      Exemplar 1 vs Exemplar 2
      Interface count+0.5833
      Msg cohesion+0.2246
      Domain cohesion+0.2386
      Inter-svc calls-19.0000
      Structural MQ+0.0679
      Conceptual MQ-0.2851
      BC penalty+0.0038
      NMI (BC align.)+0.3479
      Data ownership+0.0000
      • Classes moved: 8
      • BCs fixed (A→B): —
      • BCs broken (A→B): —
      • Δ FK crossings: +0
      • Δ shared tables: +0
      Exemplar 1 vs Exemplar 3
      Interface count+0.0000
      Msg cohesion+0.1769
      Domain cohesion+0.1026
      Inter-svc calls-6.0000
      Structural MQ-0.1986
      Conceptual MQ+0.1251
      BC penalty-0.0411
      NMI (BC align.)+0.5029
      Data ownership+0.0000
      • Classes moved: 11
      • BCs fixed (A→B): Customers
      • BCs broken (A→B): —
      • Δ FK crossings: +0
      • Δ shared tables: +2
      Exemplar 1 vs Exemplar 4
      Interface count+1.7500
      Msg cohesion+0.0109
      Domain cohesion+0.1367
      Inter-svc calls-18.0000
      Structural MQ-0.0647
      Conceptual MQ+0.0713
      BC penalty+0.0276
      NMI (BC align.)+0.5657
      Data ownership+0.0000
      • Classes moved: 8
      • BCs fixed (A→B): Customers
      • BCs broken (A→B): Visits
      • Δ FK crossings: +0
      • Δ shared tables: -1
      Exemplar 1 vs Exemplar 5
      Interface count+0.5833
      Msg cohesion+0.2246
      Domain cohesion+0.2386
      Inter-svc calls-15.0000
      Structural MQ+0.0112
      Conceptual MQ+0.1210
      BC penalty-0.0008
      NMI (BC align.)+0.4772
      Data ownership+0.0000
      • Classes moved: 9
      • BCs fixed (A→B): —
      • BCs broken (A→B): Visits
      • Δ FK crossings: +0
      • Δ shared tables: +0
      Exemplar 2 vs Exemplar 3
      Interface count-0.5833
      Msg cohesion-0.0476
      Domain cohesion-0.1360
      Inter-svc calls+13.0000
      Structural MQ-0.2665
      Conceptual MQ+0.4102
      BC penalty-0.0449
      NMI (BC align.)+0.1550
      Data ownership+0.0000
      • Classes moved: 11
      • BCs fixed (A→B): Customers
      • BCs broken (A→B): —
      • Δ FK crossings: +0
      • Δ shared tables: +2
      Exemplar 2 vs Exemplar 4
      Interface count+1.1667
      Msg cohesion-0.2137
      Domain cohesion-0.1018
      Inter-svc calls+1.0000
      Structural MQ-0.1326
      Conceptual MQ+0.3564
      BC penalty+0.0238
      NMI (BC align.)+0.2178
      Data ownership+0.0000
      • Classes moved: 10
      • BCs fixed (A→B): Customers
      • BCs broken (A→B): Visits
      • Δ FK crossings: +0
      • Δ shared tables: -1
      Exemplar 2 vs Exemplar 5
      Interface count+0.0000
      Msg cohesion-0.0000
      Domain cohesion+0.0000
      Inter-svc calls+4.0000
      Structural MQ-0.0567
      Conceptual MQ+0.4061
      BC penalty-0.0046
      NMI (BC align.)+0.1293
      Data ownership+0.0000
      • Classes moved: 8
      • BCs fixed (A→B): —
      • BCs broken (A→B): Visits
      • Δ FK crossings: +0
      • Δ shared tables: +0
      Exemplar 3 vs Exemplar 4
      Interface count+1.7500
      Msg cohesion-0.1660
      Domain cohesion+0.0341
      Inter-svc calls-12.0000
      Structural MQ+0.1338
      Conceptual MQ-0.0538
      BC penalty+0.0687
      NMI (BC align.)+0.0629
      Data ownership+0.0000
      • Classes moved: 5
      • BCs fixed (A→B): —
      • BCs broken (A→B): Visits
      • Δ FK crossings: +0
      • Δ shared tables: -3
      Exemplar 3 vs Exemplar 5
      Interface count+0.5833
      Msg cohesion+0.0476
      Domain cohesion+0.1360
      Inter-svc calls-9.0000
      Structural MQ+0.2098
      Conceptual MQ-0.0041
      BC penalty+0.0403
      NMI (BC align.)-0.0256
      Data ownership+0.0000
      • Classes moved: 5
      • BCs fixed (A→B): —
      • BCs broken (A→B): Customers, Visits
      • Δ FK crossings: +0
      • Δ shared tables: -2
      Exemplar 4 vs Exemplar 5
      B introduces one additional microservice (5 vs 4 in A) and moves two classes (PetTypeFormatter and PetTypeRepository) from service 0 to service 2. B breaks the Customers bounded context and adds one shared database table, while foreign‑key crossings remain unchanged. Metric‑wise, B improves IFN (‑1.1667), CHM (+0.2137), CHD (+0.1018), SMQ (+0.0760), CMQ (+0.0497) and penalty_swm (‑0.0284) but worsens IRN (+3.0) and NMI_filtered (‑0.0885).
      Interface count-1.1667
      Msg cohesion+0.2137
      Domain cohesion+0.1018
      Inter-svc calls+3.0000
      Structural MQ+0.0760
      Conceptual MQ+0.0496
      BC penalty-0.0284
      NMI (BC align.)-0.0885
      Data ownership+0.0000
      • Classes moved: 2
      • BCs fixed (A→B): —
      • BCs broken (A→B): Customers
      • Δ FK crossings: +0
      • Δ shared tables: +1