init: 클린 기반 auth 서버 설계

docs/examples/design/common-module.md

@@ -0,0 +1,88 @@
+# common module 예시
+
+## 좋은 예시 1: common 대신 owning module에 둠
+
+```text
+presentation/support/response/ApiResult.java
+```
+
+**왜 좋은가:**
+
+- HTTP 응답 구조는 presentation 소유다
+- 다른 레이어가 알 필요가 없다
+- 공용으로 빼면 오히려 경계가 흐려진다
+
+## 좋은 예시 2: common 대신 module API로 노출
+
+```text
+order/
+  OrderManagement.java
+order/spi/
+  package-info.java (@NamedInterface("spi"))
+  OrderLookup.java
+```
+
+**왜 좋은가:**
+
+- 필요한 범위만 공개한다
+- 전체 common으로 빼지 않고 모듈 API를 좁게 노출한다
+
+## 좋은 예시 3: 예외적으로 허용 가능한 작은 공용 타입
+
+```text
+common/types/NormalizedHost.java
+```
+
+**허용 조건:**
+
+- 여러 모듈이 실제로 사용
+- framework/business/persistence 의존 없음
+- 값 기반 타입
+- 변화 이유가 동일함
+
+**왜 좋은가:**
+
+- 진짜 공통 값 의미를 담는다
+- owning module이 특정되기 어렵다
+- 경계를 섞지 않는다
+
+## 나쁜 예시 1: 잡동사니 common
+
+```text
+common/
+  StringUtils.java
+  DateUtils.java
+  ErrorUtils.java
+  ValidationUtils.java
+  AuthConstants.java
+  ApiResult.java
+  UserMapper.java
+```
+
+**문제:**
+
+- 소유권이 불명확하다
+- web/domain/infrastructure가 섞인다
+- dump zone이 된다
+
+## 나쁜 예시 2: 경계 회피용 common
+
+```text
+common/UserDto.java
+```
+
+**문제:**
+
+- presentation DTO를 공용으로 올려 application/infrastructure도 기대게 만들 수 있다
+- DTO/Domain/Entity 경계가 무너진다
+
+## 나쁜 예시 3: premature abstraction common
+
+```text
+common/DeadlineHelper.java
+```
+
+**문제:**
+
+- task와 payment가 지금은 비슷해 보여도 미래에 독립 진화할 수 있다
+- owning module 안에 두는 편이 더 안전할 수 있다