컨벤션

이름

• 변수는 그냥 길게 쓰기 (줄여서 x)
• 축약어 라고 대문자로 사용x (ex: API, OIDC), 그냥 일반 단어럼 Api , Oidc 이렇게 사용하자
• 유의미한 단어 사용 (ex: Simple/ Light/Base X)
• 되도록 Util단어 사용x 왜냐하면 모드 static이 모이게 됨

동사

• find = return type이 Optional/ get = return type이 T 인경우
• 동사반복 x(ex: isExist -> exist 사용권장)
• get은 찾아오라는 지시가 아닌 속성정보 그대로 전달

롬복

• Getter/Setter 사용은 public 멤버변수인데 캡슐화를 망치는 주범이고 객체를 수동적이게 만든다. 여기서 수동적이란 객체가 아무것도 하지않고 위에 사진처럼 수동적인 객체를 뜻함

• TDA(tell don't ask) - 객체에게 일을 시키는 방식으로 만들자

• 주석을 달고 싶으면 메소드를 분리하라는 신호이다!

객체 지향적 코드

객체의 종류

• VO는 불변 객체라 시스템의 복잡도를 낮추는데 큰 도움이 된다. 왜냐 어떤 메서드에 호출되도 값은 일관 되기 때문

• VO는 위에 사진처럼 항상 만들어 질떄 값을 체크해줘야함

• 생성자는 값을 넣거나 값을 검증하건아 값을 할당하는 역활만 하는게 좋다

• DTO 는 상태를 보호하지 않으며 모든 속성을 노출하므로 획득자와 설정자가 필요없다 즉 public으로 해도 상관 없다는 뜻

• '보통' DB에 저장된다 = 즉 엔티티가 DB에 저장되는게 필수 조건은 아니다. 즉 엔티티는 DB와 전혀 관계가 없다

• PersistenctObject(PO) 가 맞는 표현

행동

• 데이터 위주의 사고 < 행동 위주의 사고가 객체 지향적일 확률이 높다

• Duck typing - 행동이 같다면 같은 클래스로 부른다

순환참조

• 순환참조보다는 간접 참조로 해결하자

• 또는 컴포넌트를 분리하자

• 순환참조가 없다면, 애초에 양방향 참조가 없으니까 mappedBy를 고민할 필요가 없다

-> 클래스 변수 만들때 항상 final인지 고민해보자
-> VO도 변경 메서드가 있을 수 있다.(대신 새로운 VO를 반환해야함) 일반 메서드와 구별하기위해 전치사로 시작하는 경우도 있음

Interface-Segregation

• 인터페이스는 public 메서드다. (User를 사용하는 사람은 encode메서드를 알 필요가 없다 = private)

• 인터페이스 = 이 기능을 사용하고 싶으면 이렇게 하세요

의존성을 드러내자

• 이런식으로 내부에 꽁꽁 의존성을 숨겨두면 user.login()시에 이 시간에 의존하는걸 전혀 알수 없음

변하는 값은 추상화 시켜라

• 테스트 하기 어려운 부분은 추상화를 시켜주자

CQRS

• 명령과 질의를 구분하자.
• 질의는 상태를 변경하면 안되고 명령은 return = void 여야함

습관

• 블락이 있으면 메서드로 분할 생각해보기

• 테스트하기 쉬운 코드가 좋은 코드다. 테스트를 먼저 생각해보자!

• 상속을 지양하고 Composition을 사용하자

• 과한 들여쓰기도 메서드 분할 신호이다

스프링을 OOP스럽게 사용하기

• 비즈니스 로직을 서비스단이 가질 경우 테스트 코드 작성시 덕지덕지 붙은 의존성... 즉 배보다 배꼽이 더 크게된다.
  
  

• !!!!!!!!!!!!!!비즈니스 로직을 서비스단이 아닌 도메인이 가지도록 하자!!!!!!!!!!!!

• 이렇게 어디에 넣어야 할지 모르고 애매할 경우에는

• 그냥 새로운 객체를 만들어 버리면 된다 그만큼 테코도 쉬워짐

• 이러한 객체를 도메인서비스 라고 부름( 로직 자체가 목적인 객체)

• 도메인 서비스는 이름짓기 애매해서 보통은 마지막에 Manager을 붙임

어디까지 추상화 해야 하는가?

• 시스템 외부 연동은 되도록 추상화를 하자

• 서비스는 굳이 추상화 하지 않아도 된다.왜냐 한번 생성되면 평생 같은일을 하게 되니까(but 인프라스트럭쳐 계층은 반드시)

• 도메인 계층을 만들고, 도메인 영역을 풍부하게 만들자

서비스란?

• 서비스란 DDD에서 가져온 개념이고, 비즈니스 서비스의 facade이다.

• 도메인 서비스를 만드는 것도 좋지만 꼭 그렇게 하지 않아도 됨. 하지만 좀더 OOP 스럽게, 절차지향이 아닌 객체지향으로 하고싶으면 오른쪽이 더 좋다.

• !!!!!!!!!!!!서비스는 얇게, 도메인은 풍부하게 만들자!!!!!!!!!!!!

• 서비스는 불변 이여야함

테스트

용어정리

DNS

• 도메인을 실제 서버와 연결시켜주는 서버

VIP(=virtual IP)

• 많은 서버를 대표하는 IP를 DNS에 알려준다. 로드 밸런싱의 역활도 수행함

LB-라운드 로빈

• 요청이 들어오면 순서대로 첫 서버부터 돌아가며 요청 위임함, 마지막 요청이 끝나면 다시 첫번째로 돌아감

LB- 알고리즘

• 어떻게 분산할지 다양한 방법이 존재함

L7 로드밸런싱

• 우리가 지금까지 말한 로드밸런싱은 L4단계, L7단계 로드밸런싱은 URI나 Http값 같은 걸 기준으로 로드밸런싱 함

FQDN

• 도메인 하위에 서브 도메인을 만들수 있다. FQDN은 이런 서브도메인까지 합한 full Domain

포트포워딩: 특정 포트로 들어오는 요청을 다른 포트로 변경하여 다시 요청하는 과정
DSR: Direct Server Return
Inline 구성 : LB를 프록시처럼 사용

ACL

• 주로 회사 사내망에서 외부망과 통신을 할때 사용, 일부IP, 일부 Port에 대해서만 접근이 풀려있는 화이트리스트 방식으로 ACL은 관리된다

Proxy

• 어떤 서보와 통신하기 전에 반드시 거치도록 되어있는 서버

• 요청을 간접적으로 중개하는 것을 포워드 프록시라고 한다.

• 그 요청을 받는 프록시를 리버스 프록시라고 한다.

• 흔한 프록시 flow

• nginx: 정적인페이지, 주로 프록시 역활 수행(포워드,리버스)

• SSL : http -> https로 만들어주는 보안 프로토콜

IasS/PasS/SasS

• IasS : Vm을 제공해주는 서비스
• PasS : 이미 인스톨된 환경에서 사용자는 개발만 하면 되는 서비스
• SasS: 온라인으로 액세스 가능한 소프트 웨어

온프레미스 / 온디멘드

• 온프레미스 : 자체 전산실 서버에 직접 설치해 운영하여 서비스를 전달하는 방식
• 온디멘드 : 수요가 필요한 즉시 바로 서비스를 전달할 수 있는 방식

Ha

• High Availablility의 약자

• 서비스가 다운타운 없이 얼마나 유지되나

• 가용성이 높다고 표현함

이중화

• 시스템의 일부에 어떠한 장애가 발생했을 경우를 대비하여, 장애 발생 다음에도 시스템 전체의 기능을 유지 하도록 예비 장치를 평상시부터 백업으로 배치해 운용하는 일

Active-stanBy

• 하나는 사용하지 않고 예비로 남겨둠

Active-Active(Master-Slave)

• 두가지 동시 사용

• write는 마스터에서만, read는 둘다.

• slave 는 마스터 DB replication

프로비저닝

• 사용자의 요구에 맞게 시스템을 준비 해놨다가 필요시 즉시 사용할 수 있는 상태로 미리 준비해 두는것

DR

• 시스템 장애가 났을때 어떤식으로 시스템을 복구하겠다 계획을 세우는것

• ex: 이중화 시스템 장애대응 메뉴얼

FailOver/SwitchOver/FailBack

• FailOver: 시스템에 장애가 났을경우 예비 시스템으로 자동전환 하는것
• SwitchOver: 시스템에 장애가 났을경우 수동으로 전환 하는것
• FailBack : 장애가 끝나면 예전 상태로 되돌리는것

Oauth

• 인터넷 사용자들이 비밀번호를 제공하지 않고 다른 웹사이트 상의 자신들의 정보에 대해 웹사이트나 애플리케이션의 접근 권한을 부여할 수있는 공통적인 수단

• ServiceProivder
  -사용자가 로그인 성공했는지 +Token발급(Authorization 서버역활)
  -토큰이 ServiceProvider들의 리소스 접근권한을 판별(Resource 서버역활)

CORS

• 아무데서나 내 서버를 함부로 호출하지 못하게 하는 정책
• preflight 선발대 개념 api가 먼저나감(options 메서드) 그럼 백엔드에서 api사용하고 싶으면 너의 api는 ~~여야 한다고 응답한다. 브라우저는 이걸 보고 내가 보내도 되는지 안되는지 판단해서 동작한다.

트랜잭션 격리 레벨

SQL

• 외래키는 공짜가아니다. write 성능 크게 저하

• 한방쿼리, 서브쿼리 지양하자 (쿼리에 논리를 넣지말자), 쿼리에 논리 로직을 넣어서 쿼리자체를 프로그램으로 만들지 말자

• fulltext index 사용금지

• in 쿼리는 특정 개수가 넘어가면 풀스캔을 함, 사용 지양, -> 여러번 쪼개서 쿼리 날리는게 더 좋음

• like % 는 뒤에있을때만 인덱스를 태운다