#1. 프론트앤드 아키텍트로서 고민
참고로 본인은 남이 아니라 본인 스스로만 인정하는 아키텍트다
프론트앤드 백앤드 둘다 설계하는 아키텍트다.
세상에는 엄청난 천재가 많아서 본인이 고민했던 문제를 이미 공학적으로 풀어주셨다. 바로 클린아키텍쳐다.
내 생각은 그렇다. 이름을 잘못지었다.
이름 하나 때문에 수많은 사람이 고민을 한다.
아니면 내가 생각한 문제를 푸신게 아닌듯하다.
내가 본 “Clean architecture”는
구조적 합리성으로 기획의 변화에 좌지우지되지 않고
유연한 변경이 용이하다.
라고 보였다
내가 아키텍트로서 볼 때 더 중요하게 바라보는 관점은 네이쳐이다.
개발자가 프로그램을 구성할 때, 채워나갈 때,
네이쳐의 사실관계를 모사하고 선택하여 구현을 한다.
그래야 우리가 가진 시간의 안에서 문제를 풀 수 있다.
하지만 진짜 뛰어난 개발자라면,
사실과 가깝게 프로그램을 구성할 수 있고, 사실과 생태, 자연에 가깝게 개발을 할 수 있다. 그리고 그 사실을 기반하여 표현을 조절함으로써 유연하게 대응할 수 있게 된다.
기획의 근간이 되는 사실을 얼마나 정확하고 간결하게 모사하느냐가 유연성의 근본이고, 그와 분리하여 표현의 영역을 다루는 것이 핵심이다.
클린아키텍쳐는 누가봐도 공학자가 붙인 이름이다. 별로야….
#2. Context의 정리
본인이 쓰는 context라는 용어는, 예약어를 말하는 것도 아니고 정식 명칭을 말하는 것도 아니다. 기획의 개별 줄기들을 지칭하는 말이며, 그 줄기들을 연결한 맥락을 말한다. 기준에 따라 단위는 바뀌지만 맥락 자체를 지칭한다.
React나 Angular 등의 대부분의 프론트앤드는 태생적으로 rendering pipe 를 위주로 전개될 수 밖에 없다. 그러다보니 business logic layer는 정확하고 확정적으로 구조를 강요되는 바가 없다. 그렇게 자유로운 구조를 허락한 공간은 개발자의 실력에 따라 천차만별이 된다. 또한 실력이 있는 개발자라 하여도 업력도 필요하고 시간과 공감능력도 필요하다. 그렇다 하더라도 정해진 약속이 없고 정답도 없는 영역이다.
본인도 rendering과 business logic의 분리를 몇년간 추진해온 개발자로서 정답은 못찾았으나, 원칙은 수립햤다.
#1. 프론트앤드 설계원칙
- 랜더링(presentation)과 business logic을 관점분리하여 둘다 토드로 들어날 수 있게 한다.
저것이 전부다.
business logic이 드러나지 않는 코드를 디버그해도 결국에는 business logic이 지켜지지도 관리되지도 발전하지도 못하더라.