⌨️ DB 의존 설계? DB 모델 주도?
뭔가 말만 들어도 확 와닿지 않는다. 최근 본 영상인데 비슷한 관점이 많이들 있는 거 같아서 한 번 고민해 보게 되는 것 같다.
두 영상의 내용은 전체적으론 다르지만 그 안에서 DB의존 DB모델이라는 언급이 있다. 이 부분에 대해 짚고 가볼까 한다.
한쪽에서는 개념객체(*제미니의 개발실무) 한쪽에서는 유스케이스의 행위(*하찮은 오후)가 DB에 의존한 개발에서는 명확히 표현되지 않는다고 한다.
---
우선 개념객체라는 단어는 채널주께서 본인만의 언어로 사용하시는 건데, 나의 경우에서는 본능적으로 어떠한 개념이나 기능을 객체로 나타낸 것이라고 생각을 했다.
---
1. DB 모델
우선 그럼 DB 모델 혹은 DB 의존에 대한 합의부터 이루어져야 할 것 같다.
우리가 가장 쉽게 접하는 RDB 즉 관계형 데이터 베이스에 저장될 개체들이 모델이다.
참조 . https://tech.toktokhan.dev/2021/06/28/databasemodel/
1.1. DB 의존 개발이란 무엇인가 그럼?
좀 어렵다.. 많이 생각했지만 아직 명확한 답이 그려지지 않는다.
제미니님의 영상을 봤을 때 내가 정리한 바는 이렇다.
어떤 비지니스 로직이나, 행위들이 될만한 개념 객체를 DB로 해결하려 하는 것.
우선은 이렇게 정리해볼까 한다. 내공이 더 쌓이면 다른 결론 또 나올지 모르겠다 :)
무슨 말이냐면 우리는 쉽게 상태를 DB의 칼럼을 통해 해결을 하려 한다.
isDelete라는 Boolean 타입의 칼럼으로 삭제라든지 말이다.
코드로 표현하자면
@Getter
@Entity
public class Comment extends AuditingFields {
@GeneratedValue(strategy = GenerationType.IDENTITY)
@Id
private Long id;
...
@ColumnDefault("FALSE")
@Column(nullable = false)
private Boolean isDeleted;
이런 느낌 아닐까 싶다.
이는 댓글이 삭제된다 라는 행위를 표현해주지 못하고 있다. isDeleted라는 상태만 알 뿐이다.
1.2. 그럼 어떻게 해야하는가?
영상에서는 이 부분을 CommentDelete()라는 개념 객체를 만들어서 이 객체를 통해 Comment를 또 만들어주고 있다.
Comment.of(
id,
new CommentDelete()
);
이런 느낌으로 말이다.
사실 잘 모르겠다 아직도.. 너무 개념적이고 원론적인 이야기라 그런지 와닿지가 않는다.
2. DDD인가?
DDD라고 묻는다면 또 그건 아니라고 하고 싶다. 한 영상에서는 이 개념을 DDD를 하기 위해 한 게 아닌 그저, 지속 가능하고 발전 가능한 소
프트웨어를 만드는 방법에 대해서라고 설명하고 한 영상에서는 DDD의 일환으로 설명한다.
2.1. 왜 이런 관점을?
지금 나의 제일 관심사는 '객체지향적' 그리고 지속 가능한 소프트웨어를 만드는 것이다. 그런 관점에서 공부를 하다 보니 저 두 영상이 알고리즘을 타게 된 것 같다.
무슨 말이냐면 나는 이렇게 생각한다. DDD가 아니더라도, 도메인 모델이라는 개념은 모듈의 응집도를 높여주고 객체지향적인 설계를 하게 해 준다고 말이다.
그리고 직관적이라고 말이다. 나 스스로가 정리하기엔 그렇다.
그 근거가 몇 가지 있는데,
- 코드를 보고 이해해 가 아니라 한눈에 무슨 기능이 있는지 알 수 있다.
- 각 기능들의 유지 보수가 수월해지고 확장에 열려있다.
- 이 자체로도 훌륭한 모듈이 될 수 있다.
로 정리할 수 있다.
일반적으로 우리가 Service Layer를 구성할 때를 보자
@Service
public class ArticleService{
...
public void createArticle() {
...
}
public void getArticle() {
...
}
public void updateArticle() {
...
}
public void deleteArticle() {
...
}
public void getArticleList() {
...
}
public void updateArticleList() {
...
}
public void deleteArticleList() {
...
}
}
이게 일반적으로 우리가 많이 하는 방식일 것이고 나도 그렇다. 이걸 영상에서는 이런 식으로 표현한다.
public class ArticleDomain {
Article
ArticleReader
ArticleWrtier
ArticleAppender
}
//네이밍은 임의로 했습니다.
//ArticleDomain이 어떤걸 가지고 있는 지 나타내주려고 이렇게 표현한 것이지 실제 코드는 아닙니다 :)
물론 팀원 간의 협의가 있어야겠지만 즉 Article이라는 Domain을 보면 이 Article이 무엇을 할 수 있는지 알 수 있다.
DB스키마와 DB 모델로는 알 수 없다. 물론 CRUD가 있으리란 것은 짐작 가능하지만 그 외에 더 복잡한 '비즈니스 로직'이나 기능들에 대해서는 결국 Service를 하나씩 파헤쳐가며 알아야 한다는 것이다.
3. 결론
혼자서 공부해서 쉽게 접목할 수 있을 것 같지는 않다.
무슨 말이냐면 혼자 팀원 전체를 설득해서 이런 아키텍처로 프로젝트를 리딩하기는 힘들 것 같다는 소리다.
개인 프로젝트로 이런 느낌으로 구현을 해보고, 이전에 구현했던 방식들과의 차이와 편의에 대해서 좀 느껴봐야겠다.
추가로 이 부분이 아직 확 와닿지 않고 개념적인 이해가 부족하기에, 흐릿하게만 이해하고 있다.
추후 실력이 늘고 좀 더 자세히 재포스팅을 해야겠다.
🌟REFERENCE
