<![CDATA[Identifying a service boundary is a critical decision in monolith-to-microservices migration. Intuition alone is hard to reproduce, while technical metrics without domain context can overlook business semantics. This study develops an explainable boundary-decision framework linking Domain-Driven Design (DDD), implementation evidence, and quantitative metrics for the FemaleFit e-commerce monolith. Domain mapping traced business capabilities to endpoints, controllers, models, and tables, producing 13 initial contexts and seven atomic candidates. Candidates were scored with M01–M13 under three weighting schemes (W1–W3), a practical-tie rule, and boundary sensitivity analysis. C01 Identity & Access and C03 Craft Catalog formed a practical tie, differing by 0.002803 under W1. C03 was selected on the judgement that it had clearer domain alignment, an explicit routing seam, a verified core flow, and a more contained blast radius. It was extracted as a Catalog Service behind a Strangler Gateway, with 34 unique HTTP method–path pairs reconciled against the migration contract. Functional evaluation covered one representative case for each of the 34 frozen Catalog contracts, including negative/error cases. All 540 retained read requests completed without failure across three independent runs per condition; latency findings were descriptive and mixed. The metrics indicate lower structural coupling and process-level deployment independence, but not database independence. Findings are bounded by one case, one service, a sequential local workload, and a shared database.]]>
