89 lines
1.8 KiB
Markdown
89 lines
1.8 KiB
Markdown
# 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 안에 두는 편이 더 안전할 수 있다
|