[하루 한 시간] 비즈니스 로직 격리.. 를 안하고 헛짓거리만함

오늘도 짧게 한시간..? 정도 시간 동안 어제 생각해뒀던 비즈니스로직 분리를 해보려 했는데
어디를 할까 보다가, 삭제했어야하는데 삭제 안한거 같아서 제거하고
일단 로직 자체가 분리되어있는거긴한데, 거기가 잘 안읽힌다고 거길 리팩토링..? 수정 한다고 시간이 다 가버렸다..
내일은 시간이 많이 나니까 최대한 원래의 목적만 먼저 수행할 수 있도록 해야겠다.

그리고 이동하면서 notebookLM을 통해 관련 영상이나 글을 음성파일로 들었는데 조금 정리해본다.

1. FECONF 2022 [B5] 상태관리 이 전쟁을 끝내러 왔다
   • 상태 관리의 어려움은 상태관리 자체의 문제가아니라 관심사의 분리를 제대로 못했기 때문이다 라고함
     - 그러니까 그 해답을 하고싶은건데..
   • redux나 recoil을 '전역 상태 관리' 라고 하는데 '전역'이라는 단어때문에 이 아키텍처를 오해하게 함,
     - 그러니까 내가 어제 적은 글이 이 내용과 일맥상통한다. 나도 '전역' prop drilling 문제를 해결하기 위한 도구로만 생각한게 오해라고 생각한다.
   • 아키텍처 관점에서 보면 비즈니스 로직을 담고잇는 스토어야 말고 애플리케이션의 핵심부 이며 UI는 그 핵심수에 의존하는 자주 변경될 수 있는 외부 계층에 불과하다.
     - 나도 그렇게 생각한다!!
   • 여기서는 함수형과 객체지향 둘다 상황에 맞게 사용하면 된다고한다.
   • 거대한 단일 스토어의 시대는 끝났고, 마이크로 스토어의 시대가 온다.
   • 여기서 redux가 단일 거대 스토어이고, recoil과 Zustand같은게 마이크로 스토어라고함
   • 이는 마이크로서비스 아키텍처와 유사하다고 함
     - 현재 내가 ContextAPI를 이렇게 활용하고 있음, 매번 Provider를 추가하는게 번거롭긴 하지만, 내가 원하는 도메인..? 이라고 까지 하긴 그렇지만 하나의 목적에 어울리는것만 컴포넌트에서 사용할 수 있어서 매우 만족함, 그런데 이럴꺼면 Zustand를 사용해보는걸 고려해보는게 좋을지도..?!
     • 그렇다면 결국 내가 비즈니스로직을 ContextAPI에서 해결하려고 했던 생각이 옳았던걸까?
     • ContextAPI던 Zustand던 비즈니스 로직은 다시 순수 js로 만들고, (가능하다면) 테스트 코드도 작성해서 비즈니스 로직을 검사할 수 있고 하는 구조로 하면 좋겠다.
2. Modularizing React with Established UI Patterns
   • React를 뷰로만 써야하는 이유: 아키텍처 관점의 5가지 리팩터링 원칙
   • 리액트 애플리케이션 이라는것 없다, 단지 앱을 React 뷰로 사용하고 있을 뿐
   • 핵심 원칙: 뷰와 비-뷰 로직을 분리하라!
   • 첫 번째: 커스텀 훅을 사용해 상태 관련 로직을 추출하는것
   • 두 번쨰: 순수한 뷰 컴포넌트를 또 추출하는것
   • 여기까지만 해도, 각 부분이 명확한 책임 갖게 된다고 함.
     • 어쩌면 내가 먼저 해봐야할 단계는 이건가..?!
   • 핵심원칙3: 도메인 모델로 비즈니스 로직을 캡슐화하세요.
   • 특정 비즈니스 개념과 관련된 데이터와 행위를 하나의 클래스나 객체로 묶어 중앙에서 관리합니다
   • 이 접근법의 핵심은 데이터(provider)와 그 데이터에 대한 행위(isDefaultMethod)를 한곳에 묶어두는 것입니다.
   • 이는 객체 지향 설계의 기본 원칙인 캡슐화를 프런트엔드에 적용하는 것
     • 그러니까 이 도메인 모델을 파악하고 추출할 수 있는 능력을 길러야하는데.. ㅠ 방법이 있겄지..
   • 핵심 원칙 4: '샷건 수술(Shotgun Surgery)'을 다형성(Polymorphism)으로 해결하세요.
   • '샷건 수술'은 하나의 변경사항(예: 새로운 국가 지원 추가) 때문에 코드베이스의 여러 파일(컴포넌트, 훅, 유틸리티 함수 등)을 조금씩 수정해야 하는 코드 스멜을 의미.
   • 국가별로 다른 금액 반올림 로직을 추가하기 위해 if-else나 switch 문이 곳곳에 흩어지는 것이 대표적인 예.
   • 강력한 해결책은 조건문을 다형성(Polymorphism)으로 대체하는 것.
   • JavaScript의 특성을 고려하면 더 관용적인(idiomatic) 접근법이 있습니다. JavaScript에서는 함수가 일급 시민(first-class citizen)이므로, 여러 하위 클래스를 만드는 대신 단일 CountryPayment 클래스를 만들고 생성자에서 국가별 roundUpAlgorithm 함수를 인자로 전달받을 수 있습니다.
   • 기존 코드를 수정하는 대신 새로운 전략 모듈만 추가하면 되는 유연하고 확장 가능한 시스템을 구축
     • 결국 어떤 변경 함수를 인자로 넣는.. 약간 DI개념이라고 보면 되려나..?
   • 핵심 원칙 5: 게이트웨이(Gateway) 패턴으로 외부 시스템을 격리하세요.
   • 여전히 두 가지 문제가 남아있습니다.
   • 첫째, 오류 처리나 재시도 로직이 추가되면 금방 비대해질 수 있습니다.
   • 둘째, 훅은 React 생태계에 종속되어 있습니다.
   • 해답이 바로 마지막 리팩터링 단계인 '게이트웨이(Gateway)' 패턴입니다.
   • 원시 데이터 페칭 및 변환 로직을 fetchPaymentMethods와 같이 프레임워크와 무관한 독립적인 모듈로 추출하는 것입니다.
   • 이 모듈은 외부 시스템의 영향 차단 계층(Anti-Corruption Layer) 역할을 합니다. 이 패턴의 목적은 외부 API의 변덕스럽고 복잡한 데이터 구조가 우리의 핵심 도메인 모델을 '오염(corrupt)'시키는 것을 방지하는 데 있습니다
     • 이거는 아직 정확하게 이해하지 못한것 같음. 도저히 어떤 말인지 상상이 안된걸로 봐서 다시 봐야할듯
3. Declarative UI and Data Fetching with GraphQL
   
4. 이벤트 기반 웹뷰 프레임워크 설계와 플러그인 생태계

• 위 두개는 내일 정리해볼것!