분산된 업무 규칙을 한 흐름으로 정합화하기

문제

같은 의미의 기준값을 화면, Controller, Service와 SQL이 서로 다르게 해석하면 특정 조건에서만 결과가 달라집니다. 한 화면의 결함처럼 보여도 실제 원인은 요청부터 DB 조건까지 이어지는 규칙의 불일치일 수 있습니다.

담당한 부분

비공개 Java/Spring 업무 코드에서 본인이 담당한 기준 시점과 사용자 식별 규칙의 정합화 범위를 확인했습니다. 요청부터 Controller, Service와 Mapper까지 이어지는 값의 흐름을 살피고, 각 계층이 같은 업무 규칙을 사용하도록 책임을 정리한 사례입니다.

설계 판단

• 외부 입력은 경계에서 하나의 명시적 값 객체로 정규화합니다.
• 사용자 식별과 권한 정보는 화면 입력을 신뢰하지 않고 인증 context에서 가져옵니다.
• Service가 업무 규칙과 기본값의 단일 소유자가 됩니다.
• Mapper에는 이미 검증된 명시적 파라미터만 전달합니다.
• 변경 전 결함 조건을 회귀 테스트로 먼저 고정합니다.

대안과 trade-off

각 화면을 개별 수정하면 빠르지만 동일 규칙이 다시 갈라집니다. 공통 유틸리티만 만드는 방식도 호출자가 규칙을 우회할 수 있습니다. 값 객체와 Service 경계를 사용하면 변경 범위는 커지지만 규칙의 책임이 분명해집니다.

현재 공개 범위

실제 업무명, 필드명, Mapper 원문과 운영 데이터는 포함하지 않았습니다. 현재 글은 확인된 문제와 담당 범위, 설계 판단을 일반화해 설명하며 공개 재현 코드와 회귀 테스트는 아직 포함하지 않습니다.