레이어드 아키텍처

• 스프링을 처음배우는 구조
• 의존성 역전 추상화 x

• 왠만한 문제는 대부분 레이어드 아키텍처..

• 이해하기 쉬우니 알려주는 것

• 상향식 접근은 애플리케이션이 db , jpa 종속되는 문제

• 하향식은 프레임워크에 종속 됨.

• 레스트 api 부터 고민하기 때문 .. ( 내가 이런다)

• 상향식으로 하향식으로하던 중요하지 않는 것들에 대해 집중해

• 도메인이 제일 중요한데.

• 계정 시스템을 만든다면 ?
• 이런 것들을 먼저 고민.

• use case 먼저 파악을 해야 된다.

• 이를 처리하는 도메인과 도메인 관계를 먼저 생각 해야되고

• 스프링과 jpa가 얹혀져야 된다.

• 동시작업성도 떨어짐. (근본적으로 절차지향 코드에 문제점)

• 도메인이 눈에 안들어온다.
• 객체에 대한 고민을 안함.

• 결국은 서비스가 신인 ..

• 코드는 참 어렵다.

• 도메인에 책임을 넘기자.
• 실제 업무처리는 도메인 영역

• 도메인은 어떤것도 의존하지않아 테스트 쉬움
• 레포지토리도 마찬가지 모킹 필요없음
• 굳이 테스트해야 하나 레포지토리는?
• jpa 가 알아서 처리해주니

• 엔티티는 쉽지만 레포지토리는 인스턴스화 하기 어려움

• 제어의 역전을 통해 해결

• 3개의 의존성이 존재하는 컨트롤러
• 3개의 의존성 준비하는건 시간 자원 낭비
• 여기선 서비스를 impl 만들어서 테스트하기 쉽게만듬

• 근대 추상화 한번 더했 음
• 근대 추상화할필요가 없다햇는대..

핵사고날 아키텍처 시작

• 포트 어댑터 패턴이라 해서 필요한걸 포트에 꼽는다

• 이렇게도 볼수 있음
• 구현체 입장에선 인터페이스가 포트이고 클라이언트가 어댑터일수도
• 청소기 입장에선 누가 날 사용해도 상관없지 포트를 이용해 기능제공하니까

• 이런식으로 표현하면 좋을거 같다

• 여기서 해체해서 포트어댑터를 적용해보자

• input입장 뭘 사용하든 기능만 되면되지! (포트에정의된)
• ouput 입장 누군가 날 사용해도 난 기능만 제공하면 되지 (포트에정의된)
• 내 생각을 쓰면서 얘기하니 뭔가 이해될거 같기도
• 서로가 결합이 약해 진느낌

• 그림 재 배치

• 좀더 고립시켜서 헥사고날 아키텍쳐
• 위 두그림은 똑같음

• 도메인이 순수해지고
• 인프라스트럭처 등 외부 세계에 관심이 없어지고 도메인에 충실

• 우리는 애플리케이션을 만들때 도메인 만들고
• 비즈니스 서비스 파사드를 만든다

• 이런식으로 표현 된다.

• 이건 클린아키텍처
• 용어 해석 차이만 있을뿐 본질적으로 다르지 않다
• 핵사고날이 클린아키텍쳐 실천법으로 나온 내용임

• 별볼일 없는 이름조차 주기 싫다
• 애플리케이션 본질이 아니기때문에 나중에 정하면된다 클린아키텍처에서 말함

• 이렇게 결합을 약하게 하는이유?
• 도메인만 오려서 결합하면 되니까

• 서비스를 왜추상화해야 되?
• 서비스 자체가 usecase여야 하니까

• usecase가 바뀌면 서비스가 바뀌어야된다.

• 그리고 얼추 외부 클린아키텍쳐에 맞는다

• 외부세계에서 내부세계로 향하는 방향을 단방향으로해서 내부세계를 독립시킨다

• 정답은 존재하지않는 아키텍처

엔티티

• 엔티티는 db 랑 상관 없어 !

• 근대 딱히 틀린 설명은 아닌데

• 구분하는게 꽤나 중요하다?

• 도메인엔티티 , DB 엔티티 , 영속성 객체 구분하는게 중요하다

  도메인 엔티티

  

• 도메인 객체랑 혼용되서 쓰는 용어지만

• 비즈니스에 초첨이 맞춰져 있다

• 데이터베이스에서 유 무형 객체를 표현하기위해 사용됨

• 초기 객체지향 분야 데이터베이스 분야는 비슷한 고민을 갖고 문제를 해결하기 위해 노력함

• 그래서 둘다 엔티티란 용어를 썼는데?

• 객체지향에선 클래스로 표현되고 , 디비에선 테이블로 표현됨??

  

  

• 서비스로만들려면 둘이 협업을 해야되는데
• 그리고 디비엔티티에 있는걸 도메인 엔티티로 옮겨갈 필요가 있었는데
• 그걸 도와주는게 영속성 객체고 jpa

• 도메인 엔티티 -> 고민하고있는 비즈니스 영역 해결

• 영속성 객체 -> 관계형 디비에 있는 데이터를 객체로 맵핑해주는 녀석

• DB 엔티티는 RDB에서 원래 쓰던용어

• 약간씩 다르다.

• 3개를 합치냐 마냐 호불호 문제

• 도메인 모델을 엔티티에 붙이는순간? rdb에 종속되기 때문에 분리하는게 좋다

• jpa 자체가 rdb에서 파생된 단어를써서 DocumentDB는 jpa를 따를수 없다 (단어를 틀리게..)

• 디비랑 관계가 없다 도메인 엔티티는 그래서..

코드 튜닝

• ? 스트링은 덧셈연산이 좋지 않는걸 알고 있는대
• ide는 수정하라고 해서 개선시킨 코드는 더하고 있다.

• 가벼운 연산정도는 컴파일러가 알아서 튜닝.
• 맨 아래는 자바 17 이 튜닝 해줌

• 근대 안돼는 경우도 있음.
• 그냥 StringBuilder 쓰는게 낫다
• 간단한것만 덧셈하자

• 브라켓 이용해서 로깅

• 이런식으로 굳이 로깅 찍지 않는 환경에선 덧셈연산 을하지않음
• 프로덕션 환경에 따라서.
• userId를 찍고있으니 유저수만큼 로그를 찍어 메모리 낭비가 된다.

• new는 하드코딩이임
• 이해하고 있는내용

• 예제가 없어서 와닿지 않는다.

• 푸쉬알람이 추가되면?
• ocp 위반사례 확장하려는대 기존 코드를 수정해야됨

• 컴포넌트를 추가하기위해 코드를 건들 필요가 없다

• 함수형 프로그래밍 부수효과 자체를 부정하지 않음
• 어디에나 적용 되는건 없다..

메서드

• 우리는 메시지전송?
• 수신자 메세지 전달인자
• 이렇게 수신할수 있는 메세지가 책임에 따라모이면
• 인터페이스가 된다
• 우리는 인터페이스를 통해 메시지로 객체와 객체가 소통한다
• 그리고 객체들이 메시지를 부여받으면
• 알아서 객체들은 책임지고 메세지 처리 방법을 수행한다.
• 그렇기 때문에 메서드 메세지처리 '방법' 이라서