좋은 아키텍쳐를 만드는 것은 객체 지향 설계 원칙의 이해 응용에서 출발함
객체 지향의 본질. 캡슐화, 상속, 다형성
의존성 역전
함수형 언어에선 기본적으로 변수를 변경하지 않는 것을 원칙으로 함 = 불변성
실제로는
기조를 가진다
정도가 적당할듯. 지향.
완전 함수는 불변이 전제 조건이지만, 불완전 함수도 존재하며
대부분의 함수형 언어들이 무조건 불변 변수만 다루는 것은 아님. Scala ..그렇다고 불변이라는 특성을 지향한다는 것을 무시하면 어차피 함수형 프로그래밍이 아니다.
불변성과 아키텍쳐
가변성의 분리
어플리케이션 내부의 요소를 가변 컴포넌트와 불변 컴포넌트로 분리하라
이 분리 아래 가변 변수들을 보호하는 적절한 수단을 동원해 뒷받침 해야 함
atom 은 간단한 부분에서나 커버가 가능. 어쨌거나 결국 트랜잭션 관리.
가능한 많은 처리를 불변 컴포넌트로 옮기고, 가변 컴포넌트의 역할을 줄이는 것이 좋다.
가능한 범위에서 비즈니스 로직은 불변 컴포넌트에서,
상태 변경을 동반한 트랜잭션 관리 영역의 역할을 줄인다는 컨셉으로
이벤트 소싱
상태가 아닌 트랜잭션 자체를 연속적으로 저장하고, 이들의 누적을 계산하는 발상
이런 형태는 이벤트 소싱이라는 것을 의식하지 않은 상태에서
기존 업무 로직에서 의외로 자주 접하기도 하고 사용해왔다.단지 트랜잭션 자체는 단순 추적 로그성으로 취급하는 경향이 있고,
완전 불변으로 관리하느냐 마느냐는 또 케이스 바이 케이스로 다르게 적용되어 있음
경우에 따라서는 메인 상태의 보조 상태의 역할로 구현하기도 했음하지만 엄밀히 말해 이벤트 소싱의 개념은 모든 트랜잭션 자체들을
불변의 상태로 모두 기록하고, 이들을 리플레이 시키는 것.
리플레이 시작 지점이 타협점. -> 동시성 문제를 해소함