MSA(Microservice Architecture)
서비스 규모를 작게 나누어 구성한 아키텍쳐.
포털 서비스에 MSA를 적용한다면 애플리케이션 하나에 여러 기능을 넣어 개발하지 않고 블로그 프로젝트, 메일 프로젝트, 카페 프로젝트와 같이 나누어 개발할 수 있음.
각 서버간 통신을 통해 서로의 서비스를 사용할 수 있다.
AOP(관점 지향 프로그래밍)
OOP를 더 잘 사용할 수 있게 도와주는 개념.
어떤 기능을 구현할때 "핵심기능", "부가기능" 으로 구분해 각각을 하나의 관점으로 보는 것.
클라이언트로부터 상품 정보 등록 요청을 받아 데이터베이스에 저장하고, 그 상품 정보를 조회하는 비즈니스 로직을 구현한다면
1) 상품 정보를 데이터베이스에 저장
2) 저장된 상품 정보 데이터를 보여준다
가 핵심 기능이 된다.
그리고 이 각각의 기능을 구현할 경우, 트랜잭션과 같은 부가적인 기능을 구현해야할 필요가 생긴다. 이를 구분해서 구현해야 한다.
JPA
Entity
@Entity로 해당 클래스가 엔티티임을 명시.
@Table은 사용하는 클래스의 이름과 table의 이름이 다를 경우 Table annotation을 사용해서 명시해주어야 한다.
@id로 테이블의 id 지정. 테이블에는 꼭 id가 필요하다는건 자명한 사실.
@GeneratedValue와 보통 같이쓴다.
AUTO : 데이터베이스에 맞게 자동생성.
IDENTITY : 데이터베이스의 AUTO INCREMENT를 사용해서 기본값 생성.
GeneratedValue를 명시해주지 않는다면 직접 id를 지정해 주는 것.
@Column으로 테이블 칼럼 매핑.
name : 컬럼 명을 설정.
nullable : null 처리가 가능한지 명시
length : 데이터의 최대 길이 설정
unique : 해당 데이터를 고유값으로 설정.
@Transient
엔티티 클래스에는 선언되어 있지만, 데이터베이스에서는 필요 없을 경우 이 어노테이션을 사용하면 된다.
JPArepository 메서드의 생성 규칙
JPArepository를 사용한다면 몇가지 명명 규칙에 따라 커스텀 메서드를 생성 가능하다. 단어들의 첫글자를 대문자로 설정하여 명령문을 스트링에 넣는 방식인데, 이건 보고 짜는게 나을듯.
페이징
Spring JPA는 페이징을 지원.
데이터가 많을 경우 페이지 별로 데이터를 보여줌으로써(쇼핑몰에서 상품이 많은데 여러 페이지로 보여주는 것과 같이) 효과적으로 데이터를 사용할 수 있음.
일단 개념만 보고 넘어가자.
연관관계 매핑
https://velog.io/@profile_exe/SQL-LEFT-JOIN-INNER-JOIN-%EC%B0%A8%EC%9D%B4
outer join, inner join 관련
Transaction
데이터베이스의 여러 작업을 진행하다가 문제가 생겼을 경우 이전 상태로 롤백하기 위해 사용되는 것이 트랜잭션 이다.
트랜잭션은 더이상 쪼갤 수 없는 최소 작업단위를 의미한다.
트랜잭션 커밋 : 작업이 마무리 되었음을 알리는 단위.
트랜잭션 롤백 : 작업을 취소하고 이전의 상태로 되돌리는 단위.
Spring에서는 트랜잭션 추상화 기술을 제공한다. 이를 통해 JDBC, JPA, Hibernate 등의 기술에 따른 종속적인 코드를 작성하지 않고 일관되게 코드를 작성할 수 있다.
public Object invoke(MethodInvoation invoation) throws Throwable {
TransactionStatus status = this.transactionManager.getTransaction(new DefaultTransactionDefinition());
try {
Object ret = invoation.proceed();
this.transactionManager.commit(status);
return ret;
} catch (Exception e) {
this.transactionManager.rollback(status);
throw e;
}
}이렇게 try안에 commit, 에러 발생시 catch 안에 rollback이 있는 것을 확인할 수 있다.
하지만 트랜잭션을 이런 방식으로 사용하다 보면 비즈니스 로직과 복잡하게 얽히게 된다.
REST
URI 설계 규칙
URI 는 식별자 (ex. naver.com) 이다. URL은 식별자 + 위치이다. http등의 특정 프로토콜과 결합된 형태이다. (ex. https://www.naver.com)
URL 규칙
1. URI의 마지막에 /를 포함하지 않는다.
2. _를 사용하지 않고 -를 사용한다.
3. 행위(동사) 가 아닌 결과(명사)를 포함한다.
4. 소문자로 작성한다.
5. 파일의 확장자를 포함하지 않는다.
Reactive Programming
WebFlux
WebClient
NotNull, NotEmpty, NotBlank
@NotNull -> null만 허용하지 않음.
@NotEmpty -> null과 "" 둘다 허용 안함
@NotBlank -> null, "", " " 모두 허용하지 않음.
DTO(Data Transfer Object)
계층간 데이터 전송을 위한 도메인 모델 대신 사용되는 객체
DTO는 어떠한 비즈니스 로직도 가지면 안되고, 데이터에 대한 getter, setter만 가져야 한다.
DTO does not have any behavior except for storage, retrieval, serialization and deserialization of its own data
serialization : DTO를 Byte, Json, Xml등의 형태로 변하는 것.
deserialization : 그 반대.
DTO 가 persistence layer까지 도달하는 것을 지양하고, presentation layer에 노출되면 안된다. 그러므로 서비스 레이어에서 DTO로 변환되어 전달되는 형식을 가져가야 한다.
DTO와 Domain model의 변환은 별도의 Mapper 객체를 사용한다고 한다.
Layered Architecture
Presentation layer
view, controller를 포함한 layer. controller를 따로 떼서 Controller layer로 사용하기도 한다.
controller에서 구성 요소 간 처리 흐름을 제어하고 데이터 조작 의뢰, 데이터 변환 및 연산, Exception과 Error 처리를 한다.
Application + domain layer/Business layer
Service, Domain layer에 해당하는 부분.
Controller layer와 Persistence layer를 연결하는 역할.
Service는 고객이 원하는 요구 사항을 반영하는 계층으로, 고객의 요구사항과 정확히 일치하도록 설계해야한다.
Domain은 비즈니스 로직이 담기는 곳으로 알고리즘 및 프로그래밍 구성요소를 담당한다.
Persistence layer
엔티티 객체를 보관하는 Repository, 데이터에 접근하도록 DB 접근 관련 로직을 모아둔 DAO가 있음.
어떤 방식으로 데이터를 보관 혹은 사용하는가에 대한 설계가 들어가는 계층.
3 tiers , 4 tiers
Application + domain으로 나누면 4tier, 아니면 3tier임.
