오전 수업은 배포 스크립트에 관한 것이었다. 거의 실습에 가까웠다.

빌드나 부트런을 하다가 죽는경우는 메모리가 부족하거나 크레딧이 부족한 경우라고 한다. 서버를 물리적으로 여러 사용자에게 제공하기 때문에 허용 되는 시간 당 사용량이 있는데 이 것을 크레딧이라 한다.

리눅스에서 터미널이 종료되면 SIGHUP이 실행된다고 한다. 이걸 자식 프로세스들이 받아서 특별한 동작이 지정되지 않았으면 종료되는데, 이걸 막아주는 방법 중 하나가 백그라운드 프로세스로 돌리는 것이다.

그런데 의문점이 하나 생겼다. 호눅스는 백그라운드 프로세스로 돌리는 것으로 마무리 했는데, 예전에 서버를 처음 돌려봤을때 NOHUP을 사용하지 않으면 제대로 돌아가지 않았다. 세션에서 나가고 일정 시간 뒤 프로그램이 터졌는데, 차이점은 로그를 따로 뺐느냐 이다. 어쩌면 NOHUP도 로그를 직접 출력하지 않고 파일로 리디렉션 시키기 때문에 터지지 않았던 것이 아닌가 하는 생각도 든다. 직접 테스트를 해봐야 할지... 아니면 학습을 위해 호눅스가 일부러 설명을 하지 않은 것인지...

오늘도 하루를 설계에 쏟았다. 혼자 설계하는 시간이 길어지니 생각도 잘 안 나고, 집중도 많이 떨어졌다. 혼자 머리 식히는 시간이 너무 많아져서 속도가 더뎠는데, 그래도 머리 식히고 잠깐잠깐 반짝 하는 아이디어들이 조금 쌓여서 어느정도 구색은 갖춘 것 같다.

문제는 복잡도가 증가했다는 점과, 그래도 놓지는 부분이 있다는 것이다. 아무래도 db에 너무 갇혀있는 것 같아 다시 api를 보기로 했다. 사실 목업도 제공해야 할 것이기 때문에 어쨌든 api설계는 빨리 마무리 해야한다. 뷰 단도 마무리가 어느정도 되었다고 하니...

api 구조를 만들어보다 느낀 점은 계층이 아주 깊어진다는 것이다. 우리는 이런 구조를 자주 사용한다. mvc도 사실 이와 다름없지 않은가. 대신 mvc는 인터페이스를 이용하여 의존을 역전시키려는 노력을 한다. DIP를 공부했을때 생각했던 계층 분리 덕에 상위에서는 하위를 몰라도 된다.

이런 구조를 Spring Data JDBC에서도(어쩌면 DDD일지도 모르겠다) 비슷하게 구현할 수 있다. 정확히는 RDB 테이블에서 표현할 방법이 있다. 관계 테이블을 이용하는 것이다. 관계 테이블을 사용하면 각 객체간의 직접적인 관계가 끊어진다. 즉 해당 계층부터 새롭게 시작해야 자연스러워진다. 어쩌면 aggregate root 간의 인터페이스를 관계 테이블로 생각한게 아닌가 싶다.

이전 미션에서 살펴봤듯이 aggregate root를 쌩뚱맞은 것으로 가져가면 뭔가 이상한 느낌이 많이 든다. 이런 기시감이 아마 현재 내가 생각하는 것 때문이 아니었나 싶다. 그리고 이렇게 정리해보니 왜 도메인 드리븐인지 어느정도 알 것 같다. 도메인에 대한 이해도가 없으면 절대 설계가 불가능하다. 어디를 root로 잡고 어느 부분에서 인터페이스를 만들어 놓을 것인지에 대한 통찰이 필요하다. 특히 root를 나눈다는 것은 도메인의 경계를 구분한다는 것인데 단순히 데이터적인 관점에서 본다면 이해하기가 힘들 수도 있겠다. 이전 미션의 카테고리가 이 경우였을 것이다.

지금 당장 해야 할 일은 이 경계를 어떻게 설정할 것인지, 그리고 경계에 따라 api를 분리할 것인지가 되겠다. api에 대해서도 생각이 많은데, 초기 데이터를 어디까지 가져올지, 그리고 리퀘스트는 어떻게 분리할지가 관건인 것 같다. 사실 잘게 나눈 뒤 프런트에서도 프로미스로 묶으면 될테지만, 얘기를 잘 해봐야 하는게 아닌가 싶다.