유투브 조영호님의 강의 영상 후기

레이어 아키텍쳐

일반적으로 레이어 아키텍쳐는

프레젠테이션 ( 사용자 입력을 받는 부분 , 화면쪽)

도메인 ( 주요 로직)

데이터 소스 ( 디비쪽)

으로 나뉘고 주요 로직인 도메인 레이어가 가장 중요함.

도메인 레이어

이 도메인 레이어는 두가지 설계 방법이 있는데

1. 절차지향 → (트랜잭션 스크립트 모델)

1. 객체지향 → (도메인 모델)

두가지 방법이 있고 괄호안은 모델 패턴의 이름.

우리나라는 대부분 데이터와 로직이 나뉘어져 있는 절차지향.

절차지향

1. 절차지향은 서비스에 주요로직이 있고 데이터 모델이 따로 있고 DAO를 통해서 데이터를 가져옴

→ 프로세스와 데이터가 나뉘어져 있음.

객체지향

2. 객체지향은 로직과 데이터모델이 하나로 존재함.

→ 프로세스와 데이터가 합쳐져있음. (객체)

→ 다른 객체( 프로세스와 데이터) 들과의 서로 상호작용 할수있는 구조.

객체지향 설계

CRC Card

책임과 협력을 표현하기 위한 객체지향 설계도구

C. Candidate = 역할 또는 객체

R. Responsibility = 객체가 맡은 역할 ( 로직 )

C. Collaborator = 객체가 맡은 역할을 수행하기 위해 필요한 객체

객체지향 설계 방법

1. 로직을 수행할때 필요한 데이터들을 가장 많이 갖고있는 객체에 로직을 할당. ( creator 패턴)

   → 객체에 로직을 넣기 힘들경우 팩토리 객체를 만든다.

1. 1번의 객체에 로직을 수행하는데 다른 데이터가 필요할 경우 다른 객체의 협력이 필요. ( 호출 )

객체지향 결론

절차지향에서 처럼 하나의 서비스에 모든 로직을 다 집어넣는것이 아닌

각각 알맞는 객체 ( 로직을 수행할 데이터를 가장 많이갖고있는 객체) 에 로직을 할당하며

객체간의 협력관계로 로직을 수행하는것.

도메인 레이어와 아키텍쳐

도메인 레이어를 어떻게 설정하느냐에 따라서 아키텍쳐가 조금씩 틀려진다.

1. 어플리케이션 플로우 로직

도메인 로직을 처리 하기 위한 전후 작업 ( 디비에 넣는다던지 , 푸쉬후 카톡이나 메신저에 전송할때)

어플리케이션 로직을 도메인 로직에 넣으면 의존성( 디비에 넣을땐 디비쪽 의존성)이 생기므로 테스트가 어려워지고 결합도가 높아지고 응집도가 떨어지므로 도메인 로직에 넣지 않음.

2.도메인 레이어 캡슐화

도메인과 관계없는 로직들은 접근 못하게 막아야한다.

3.서비스 레이어

그래서 나온것이 서비스 레이어.

어플리케이션 플로우 로직을 서비스 레이어에 넣는다.

프레젠테이션

서비스

도메인

데이터소스

도메인 레이어 위에 서비스 레이어가 붙는다.

서비스 레이어는 달라도 도메인 로직은 사용이 가능하므로 도메인 로직의 재사용성이 높아진다.

서비스 레이어가 시작할때 트랜잭션이 시작하고 서비스 레이어가 끝날때 트랜잭션이 끝난다.

데이터 소스 레이어

객체모델과 db스키마 사이의 불일치

객체 모델과 DB 스키마 사이의 불일치.

객체 패러다임과 관계 패러다임 간의 불일치.

데이터는 중복 제거하기 용이함.

객체는 유연하다. 수정이 쉽다.

객체지향적으로 볼수록 둘사이는 관점이 다르므로 불일치가 일어남.

이럴경우 datamapper를 두고 양쪽의 불일치를 해결하게함.

datamapper를 사용함으로써 객체와 데이터의 결합도를 낮춘다.

결합도가 낮으므로 서로가 다르게 발전함.

ORM

ORM = datamapper

대표적인 ORM = HIBERNATE , JPA

절차지향의 단점

1. 로직을 찾기가 힘들고 알아보기도 힘듬.

2.수정하기가 힘듬.

객체지향의 장점

1. 로직을 찾기도 쉽고 수정하기도 쉽다.

2. OCP open-closed principle

수정은 닫혀있지만 행동을 변경하고 확장하는것엔 열려있다.

추상화를 기준으로 분리.

3.dependency-inversion principle 의존성 역전 원칙

추상화를 기준으로 분리하면 상위 레벨의 모듈은 하위 레벨의 모듈에 의존성을 전혀 갖지 않는다.

의존성은 같은 레벨단계에서만 가짐.

의존성을 추상화로 향하게 하면 시스템의 확장성이 늘어남. ( 2020.06.28 확실하게 이해가 되진않음 )

4. 추상화를 이용한 효율적인 커뮤니케이션이 가능.

하이레벨모듈로만 얘기 가능하고 더 디테일하게 내려갈경우에 로우레벨모듈에 대한 설명이 가능하다.

계속해서 추상화를 만들다 보면 이것들이 모여서 도메인 레이어가 됨.

객체지향의 단점

객체지향으로 설계할때는 최대한 쉽게 로직을 짜야한다.

하지만 이런경우는 거의없다. 그래서 매번 리팩토링을 해야한다.

어느정도 방향성이 보이기 시작하면 그때부터 편해진다.

https://www.youtube.com/watch?v=26S4VFUWlJM&feature=youtu.be

2020.06.28 - 어느정도 윤곽과 개념이 잡힘.

1. jenkins 와 git 연동

  -  jenkins의 포트는 설정한 8081이다 

  -  jenkins에 접속하면 처음에 암호를 입력하라고하는데 docker logs 컨테이너이름으로 로그를 보면

    중간에 암호가 나와있음 그거 입력하고 들어가면됨.

  -  https://ict-nroo.tistory.com/35

   이 블로그의 글을 그대로 따라한다. maven으로 빌드할사람은 빌드도구설정 전까지 따라한다.

  - 빌드도구설정에 maven 버전을 지정하기 위해선 global tool configuration 에 가서 maven installations를 클릭

  - 내 버전은 363이므로 이름에 mvn363 작성 install automatically 체크 apache버전도 동일하게 맞춰주고 저장.

  - 저장한 메이븐버전을 빌드도구설정에서 지정해줌

  - goals는 clean package

  - pom은 추가안해도되나 git에 루트가 폴더로 시작하면 앞에 폴더/pom.xml로 작성해준다.

  - 그리고 빌드유발에서 github hook trigger for GITscm polling 체크해준다.

  - 빌드 환경은 빌드가 실패했을경우 실행할때 사용할수있다.

  - Send files or execute commands over SSH after the build runs 는 빌드가 실패 성공되든 상관없이 명령을 수행

  - 이대로 잠시 냅두고 시스템 설정으로 가서 Publish Over SSH에서 ssh설정을 해줘야 한다.

  - publish over ssh 탭에서 key 항목에는 aws ec2 인스턴스 생성하면서 받은 pem파일의 정보를 넣어줘야한다.

  - begin 부터 끝까지 다 작성한다.

  - 그리고 ssh servers 항목을 다 작성해준다.

  - 자세한 설명이된 블로그

  - https://kamang-it.tistory.com/entry/Jenkinsssh%EC%9D%B4%EC%9A%A9%ED%95%B4%EC%84%9C-%EB%B9%8C%EB%93%9C%EB%90%98%EA%B3%A0-%EC%8A%A4%ED%81%AC%EB%A6%BD%ED%8A%B8-%EC%8B%A4%ED%96%89%ED%95%98%EA%B8%B04

  - 그 후빌드 후 조치에서 Send Build artifacts over ssh 선택

  - name 작성해주고 transfers 에 transfer set 에서 source files는 자기에 맞게 작성

  - 그리고 Exec command에서는 도커 명령어를 작성한다.

  -  docker stop spring-boot-book 
     docker rm spring-boot-book 
     docker-compose up -d bootapp

  - 도커 컨테이너 정지 후 삭제

  - 도커 컨테이너 재 생성 후 실행

  - 그리고 저장하면 완료

  - 자세한 설명

  - https://kamang-it.tistory.com/entry/Jenkinsssh%EC%9D%B4%EC%9A%A9%ED%95%B4%EC%84%9C-%EB%B9%8C%EB%93%9C%EB%90%98%EA%B3%A0-%EC%8A%A4%ED%81%AC%EB%A6%BD%ED%8A%B8-%EC%8B%A4%ED%96%89%ED%95%98%EA%B8%B04

  - https://yookeun.github.io/tools/2018/04/14/jenkins-remote/

  - https://hnlee.tistory.com/2

이하의 블로그를 참조하면 됨.

참고. pipeline은 다루지 않음.

1. aws 결제

  - 프리티어는 jenkins가 테스트케이스 작성하다 뻗을수있음.

  - 프리티어 바로 위에꺼로 결제함.

  - 리눅스로 권장.

  - aws 인스턴스에 ssh 접속방법

  - https://docs.aws.amazon.com/ko_kr/AWSEC2/latest/UserGuide/putty.html

2. docker , docker-compose 설치.

  2-1. docker 설치

   - https://docs.aws.amazon.com/ko_kr/AmazonECS/latest/developerguide/docker-basics.html

2-2. docker-compose 설치

   - https://docs.docker.com/compose/install/

3. docker 로 jenkins , boot , postgresql 서버 띄우기

   3-1. jenkins 서버 띄우기

      - dockerfile 작성

      - https://kingds.tistory.com/32

     - docker-compose.yml 작성

     - https://kingds.tistory.com/33

    - 작성 후 docker-compose up -d jenkins-awscli 를 입력 jenkins_awscli는 compose에서 설정한 서비스이름.

3-2. postgres 서버 띄우기

     -  docker에서 pull로 postgres 이미지를 받는다. 

     -  https://kingds.tistory.com/33

    - 세팅에 맞게 작성후 docker-compose up -d 

3-3. boot app 서버 띄우기

     - boot app은 docker-compose 설정파일만 작성해서 추가해놓는다.

jenkins_awscli

============================================

version: '3'
services:
        jenkins_awscli:
                restart: always
                image: ds/jenkins_cli:1.0
                volumes:
                        - ~/jenkins:/var/jenkins_home
                        - ~/.aws:/root/.aws
                ports:
                        - "8081:8080"
                        - "5000:5000"
                user: root

============================================

postgres

       위의 설정에 아래 설정을 그대로 이어서 붙어서 써준다.

============================================

       postgres:
                restart: always
                image: postgres
                environment:
                        - POSTGRES_USER=testuser
                        - POSTGRES_PASSWORD=testpass
                        - POSTGRES_DB=testbook
                ports:
                        - '5432:5432'
                volumes:
                        - ~/postgresql/data:/var/lib/postgresql/data

============================================

boot app 

        위의 설정에 아래설정을 그대로 이어서 붙어서 써준다.

============================================

 bootapp:
                image: openjdk:8-jdk-alpine
                restart: always
                container_name: "spring-boot-book"
                ports: -  "9765:9765"
                command: "java -jar app.jar --spring.config.location=file:///application-release.yml"

                environment:
                        -  "SPRING_PROFILES_ACTIVE=release"
                volumes:
                        - ~/boot/book/app:/usr/src/myapp
                        - ~/boot/book/env:/root/env
                        - ~/boot/book/log/spring:/log/spring

                        - ~/jenkins/workspace/git/bookReview/target/bookReview-0.0.1-bookReview.jar:/app.jar

                        - ~/properties/application-release.yml:/application-release.yml

               depends_on:

                        - postgres

============================================

- jar파일을 이어놓은이유는 따로 파일 옮길필요가 없이 바로 aws서버에서

도커명령어로 이미지를 만들기 위함이고

- application.yml도 이어놓은이유는

  깃이 퍼블릭으로 되어있는데 디비정보를 올릴수없어서 깃에는 기본 메모리db h2를 이용하게하고

  서버에 올려논 yml은 디비정보를 입력하여 디비에 접속가능하게함.

- java properties outside jar

- https://www.baeldung.com/spring-properties-file-outside-jar

https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#boot-features-external-config-application-property-files

docker-compose 

자세한설명 : 

https://www.44bits.io/ko/post/almost-perfect-development-environment-with-docker-and-docker-compose#docker-compose.yml-%ED%8C%8C%EC%9D%BC

docker-compose postgresql 

https://www.javacodegeeks.com/2020/03/docker-compose-for-spring-boot-application-with-postgresql.html

https://siner308.github.io/2019/03/02/postgres-docker-compose/

https://docs.docker.com/engine/examples/postgresql_service/

1.  별다른 설정이 없으면 setter가 없으면 source에서 destination 으로 값이 바뀌질 않는다.

2.  ddd에선 setter를 권장하지 않는다.

3.  이럴경우 configuration 에서 fieldaccesslevel을 필드의 레벨로 정해주고

4.  fieldmatchingenabled를 true로 주면 끝.

post 엔티티에는 OneToMany List타입의 comments 필드가 있고

comment 엔티티 에는 ManyToOne Post타입의 필드가 있다.

comments 필드에는 mappedBy post가 걸려있다.

comment 엔티티에는 대댓글을 위한 selfjoin이 걸려있고

OneToMany List<Comment> 타입의 childList 필드와 ManyToOne comment 타입의 parent 필드가 양방향으로 걸려있고

단방향으로는 Comment 타입의 group 필드가 있다.

이렇게 연관관계 설정이 되어있고 댓글과 대댓글을 표현하기위한 group 필드와 parent 필드 childList필드가 있다.

뷰에서 depth가 0인 댓글들을 보여주고

그 밑의 댓글들은 childList에서 가져다가 뿌려주는 방식으로 처음 가닥을 잡았다.

그래서 처음에는 post 엔티티에서 가져다가

comments 필드안에 있는 튜플들의 각각의 childList를 가져다가 뽑아줄려고 했으나

문제가 발생

Hibernate MultipleBagFetchException

(OneToMany 또는 ManyToMany 를 설정한 필드를 동시에 가져오려고 시도하면 나타나는 에러)

해결책은 List 타입을 Set 타입으로 변경하면 에러가 사라짐.

이외 에도 entitygraph를 사용하고  fetch join 시 조건을 줄수 없으므로 

필드위에 @Where과 @OrderBy를 사용해서 쿼리를 만들었으나

가져오는 쿼리 where로 따로 가져오는 쿼리 orderby 정렬하는 쿼리 가 발생하여

총3번의 쿼리가 발생함.

그래서 그냥 comment 엔티티에서 값을 가져와서 뿌려주는 방식으로 변경

포스트 와 코멘트 2번 가져오는 쿼리로 변경.

그냥 querydsl로 뽑을때 nested하게 뽑으면 되는 상황이였다.

builder 로 객체를 생성할때 초기화 되지 않은 변수는 null인 상태고 변수에 값이 지정되어 있어도 null이다.

enum은 올디널 타입과 스트링 타입 2가지가 있다.

올디널 타입은 enum 값에 번호를 매겨서 번호로 지정하는 방식이고

스트링 타입은 문자열로 지정하는 방식이다.

올디널 타입 사용시 혹시 누군가가 enum 클래스에 새로운 값을 추가한다면

번호가 변경되므로 소스에 치명적이다.

하지만 스트링 타입을 사용하면 직접호출하는것이기 때문에 문제가 없다.

default는 ordinal 이므로 string으로 선언해 주도록 한다