클린 아키텍처 (4.내가 궁금했던 점)

immutable과 service interface

 

1. immutable

immutable은 thread 안전?

말로는 알겠는데 해당 사고를 경험한 적은 없다.

나모한테 자문해보니 어느 정도 궁금증은 풀렸는데 해당 사고 경험 얘기는 듣지 못했다.

 

이것은 다시 캡슐화(Encapsulation)가 소환된다.

저 멀리 2000년 초반까지 간다.

C++을 배우고, JAVA를 배우면서 암기강요 당했던 캡슐화.

교수님들 캡슐화의 필요성을 느껴보긴 했을까?

그 당시에도 이런 기법에 대해 이해시켜 주는 사람이 단 한 명도 없었고 사례를 말해주는 사람도 없었다.

그냥 객체지향의 장점: 캡슐화를 통한 은닉?

도대체 어쩌란 거지;;;

변수는 private , 함수는 public 공식 

그렇게 배웠고, 꽤 오랜 기간 그렇게 써왔다.

 

5~6년 전쯤 함께 일했던 개발자와 꽤나 투닥투닥을 많이 했었다.

개발에 대한 관점이 거의 양 극에 있는 분이었는데,

밥형의 말을 빌리자면 소프트웨어의 두 가치 중 첫 번째인 행위(behavior)에는 관심이 있지만 두 번째 가치인 부드러운(soft) 즉, 아키텍처에는 정말 1도 관심이 없는 분이었다.

어차피 수정할 때 모든 것을 찾아내서 수정하면 되니까 (실제로 모든 소스를 줄 단위로 외우고 계신다.)

나야 뭐.. 내 소스에 대해 기억을 일부러라도 지우니까 (꽤 오랜 기간 훈련도 했다. 내가 짠 소스를 잊으려고)

이 분께서 상상도 하지 못한 방식으로 함수를 만들고, 접근하고, 변경하는 것들을 보고 강하게 느꼈다.

나의 객체를 보호하기 위해 캡슐화를 했다.

다행히 private나 protect를 굳이 public로 변경하진 않으셨다.

 

이후로 public는 만들지 않는다.

무조건 필요한 경우에만 public로 변경해 나간다.

 

immutable도 동일하다.

특히 할당을 하지 않는 함수형에서는 무조건 immutable

필요한 경우 mutable 적용.

당연히 모든 것은 바뀌니까 mutable이 맞다. 다만 필요한 곳을 제한하는 것이다.

...

아직은 사고를 안 당해서 public처럼 와닿지는 않지만.

 

2. service interface

우리는 service에서 interface는 사용하지 않는다.

내가 이 부분을 진저리 치게 싫어하는데,

개발 시작하고 spring으로 된 소스를 만날 때마다 의미 없는 service interface를 너무 많이 경험했다.

심지어 interface를 만들어두고 controller에서는 service implements를 선언해서 사용한 것도 본 적 있다.

이게 아마 annotation이 그 구조로 하기가 어려울 텐데 진짜 신의 영역이었다.

 

여기서 사용한 interface는 설계적인 부분이 크다고 생각했는데,

이것도 역시 의존성 역전이었다.

 

service interface가 없는 것

servece intreface가 있는 것

사실 이 부분도 immutable과 비슷한데,

아직도 소규모만 해서 그런지 와닿지가 않는다.

어차피 interface는 없지만, 대부분은 내용이 바뀌는 부분이고,

규격(interface)이 바뀔 때는 양쪽(client-나의 경우는 controller, service implements을 다 건드려야 하니 눈에 잘 띄긴 한다.

 

data가 세부사항이라는 대한 얘기를 하자면 어차피 service interface가 없더라도 의존관계가 외부(contreller)->내부(service)로 흐르고 있으므로 문제는 없는 상황.

 

일단은 당분간 귀찮지만 interface를 만들어보고 느껴봐야겠다.

 

사실 MVC에서 controller의 역할에 대해서도 10년 넘게 생각을 해봤는데,

최근에 react,vue를 사용하면서 api를 강제로 만들게 되니 의존성 역전을 더 이해하게 되었다.

 

내가 해왔던 대부분의 프로젝트에서 대부분의 개발자들은

view -> controller ->service -> dao 

의 흐름을 가지고 page 기반으로 만들고 있다.

이러다보니  c나 c++로 html까지 만들어버리거나 jsp,php에 비해서 오히려 더 열악해진다.

우리가 관리하는 넘겨받은 프로젝트들에도 이런 부분이 많다.

어차피 모두 1회밖에 안쓰는 로직들이 저렇게 나뉘어 있으니 고통이 배가 된다. 

심지어 화면 하나 고치는데 interface까지 있으면...

 

심지어 최근에 react (backend는 node) 로 개발했는데,

front에서 api를 호출해서 backend (api->model) 구조인데도 불구하고 화면에 지배되는 모델로 짜고들 있었다!

 

결국 controller과 동일한 역할을 service interface가 하는 것인데 아직도 고민인 이런 상황.

자자 불편해도 일단 만들어서 써보자고.

 

20230504

만들면서 배우는 클린 아키텍처에 위 고민이 언급된다. 

138page 인커밍 포트(내가 궁금한 service interface) 건너뛰기

인커밍포트 건너뛰기

저자에 따르면 이렇게 해도 되지만 두 가지 의견이 있다고 했다.

1) 진입점 식별 - 후임자가 봤을때 간결하고 명확한 확인

2) 아키텍처 강제 - 인커밍포트를 강제하게 하는 팀훈련

 

즉, 적어도 현재 우리팀에서는 인커밍포트를 두는 것의 손해가 이득보다 훨씬 큰 상황이긴한데,

미래 우리팀까지 고려해서 직입점 식별 및 아키텍처 강제를 해보자.

 

3. python 에서는?

파이썬에서 interface로 의존성 역전하는 부분은 어떻게 구현할까?

결국 의존성 역전에 interface가 필요한 이유는 소스의 제약 때문이다!

controller은 service의 세부를 알고 싶지 않고, service implements는 controller가 변할때 타격을 받으면 낭패이니까.

아무래도 내 모국어는 java인데 파이썬에 매력에 빠지나보니 이런 부분이 궁금하다.

소규모의 프로젝트는 파이썬으로 가능하겠지만, 규모가 커질때 아키텍쳐는 역시 모국어를 이길 수는 없을 듯.

코틀린을 대비해야하는 이유.

 

의존성 역전은 죽을때 까지도 결정이 안 날듯하다.