@ 외주 턴키2026Full-Stack
AI Career Diagnosis App for Retirees
MVP shipped in 2 months (solo full-stack). Validated: 4.6 on Google Play, 1,000+ downloads.
View details
AI Product Engineer
★ Case 06 / 6Product Engineer Donghyun Kang
Bizprint Business Card & Print E-commerce
Moving 10-year ASP legacy to Java 17 was never a tech problem — it was a problem of understanding the floor.
외주 턴키Full-Stack2024.02 ~ 2024.08
01.Discover
The spaghetti was a symptom, not the disease.
The turnkey brief looked simple — "move 10-year ASP legacy to Java 17." Once I looked inside, it was not about moving code to a new stack; it was about redrawing the domain embedded in it. Spaghetti code, new features deployed with a prayer, maintenance with no clear blast radius — all symptoms of the same fact: the domain model was not written into the code.
The print and business-card domain is one flow — order → design review → print and production → shipping. In the code, that flow was scattered across separate modules, and every transition to the next step required a human hand and tacit context. Before switching stacks, the real starting line was a single question: *can this flow be expressed as one model in the code?*
Field notes
Note 01
The spaghetti was a symptom
The real reason new features always shipped on a prayer was the missing domain model, not the code quality.
Note 02
Order, production, shipping disconnected in code
One flow on the floor, but disconnected modules in code — every transition needed a human hand and context.
02.Build with AI
Re-modeled it in the language of the domain.
Decision 01
Data modeling driven by the process flow
Instead of the standard migration order of "switch the stack first," I defined the domain model first. If the print process flow cannot be expressed as one model in the code, the same spaghetti will reappear on any stack.
BeforeOrder, production, and shipping each in their own module
AfterOne process flow on one model — order → design → print → ship
tradeoffStack modernization first vs. domain model first
Decision 02
Unified full pipeline — order to delivery on one flow
Folded order, production, and shipping into one flow inside one system. Removed the pattern of needing a human hand at each transition, and let the system trace the full lifecycle of an order all the way through.
Decision 03
Java 17 + Spring Boot 3.x — the seat that absorbed the model redefinition
The move from ASP to Java 17 + Spring Boot 3.x was not a stack swap — it was the exact moment the domain model could be redrawn. The process-flow model became first-class on the new stack.
03.Prove with metrics
It turned into a system you can deploy without a prayer.
Legacy
10 years of ASP → Java 17
Not a stack swap — a domain-model redefinition
Process
Disconnected → one flow
Order → design → print → ship unified
Deploy
Prayer → traceable
A system where new features land safely
Ownership
Turnkey contract, full-stack
From domain discovery to migration, one person
What this case is really about
“Technology only pays off when it can speak the language of the domain.”
Discover
Named the real cause of the spaghetti: not code quality, but a missing domain model.
Build
Data modeling driven by the actual process flow, a unified full pipeline, and the model re-defined on Java 17.
Prove
Rebuilt a "pray and deploy" system into one where the domain flow is first-class — solo, turnkey, full-stack contract.
Linked principlesDomain-DrivenPragmatism
More work
