DevBoi

* 명령 조회 책임 분리 * 커맨드 실행 모델 : 비즈니스 로직 구현, 강력한 일관성 * 읽기 모델 : 인메모리 캐시, 일반 파일, materialized view, 읽기 전용 * 동기화 필요 : 동기식, 비 동기식 * 확장, 읽기 성능,다양한 저장소 커맨드에서 들어온 저장소와, 읽기에서 들어간 저장소가 다른것이 좋은데 이 두개 다른 저장소에 대한 일관성을 유지해주는 것이 좋다. 따라서 쓰기 데이터 저장소와 읽기 데이터 저장소를 분리하지만, 해당 데이터에 대한 일관성은 유지해주는 것이 좋다. 데이터 동기화는 동기식이던, 비동기식이던 필요하다. 두개는 비동기식으로는 메시지 큐를 이용해도되고, CDC를 이용해서 동기식으로 해도된다. 일단 CQRS의 가장 큰 이유는 커맨드에 따른 일관적인 데이터 쓰기 이고 읽..

레이어드아키텍처의 개선방향으로 아키텍처에 대한게 두가지 정도있다. 비즈니스 로직은 내부영역에 놓고, 외부영역에 즉 가변적인 영역을 외부에 놓는다. 클린아키텍처는 아래와 같다. 서비스는 유스케이스에 해당 된다. 원리는 헥사고날과 비슷하다. 가변적인 영역을 외부에 놓고, 비즈니스 로직을 내부에 놓는다. 외부 서비스에서 Aggregate를 호출하고, 혹은 프록시나 이벤트를 사용한다. 서비스는 필요시에 비즈니스 도메인인 Aggregate를 호출하고 이는 엔티티나 VO를 호출하게된다.

마이크로서비스 내부 구조 정의는 어떻게 해야할까 전술적 패턴은 비즈니스 로직을 모델링하고, 구현하는 다양한 방법이다. 가장 고전적인 아키텍처는 3계층으로 구현하는 것이다. 프리젠테이션 레이어, 비지니스 로직 레이어, 데이터 엑세스 레이어 이렇게 3가지 레이어가 존재한다. 레이어드 아키텍처 근접 레이어만 접근 가능하다 Top-down 아래로 의존적이고 순방향이다. 흔히아는 MVC컨트롤러는 프리젠테이션 계층에 속한다. 가장 중요한 계층은 비즈로직 계층이다. 레이어드 아키텍처 다양한 변종이 존재한다. 레이어드 아키텍처는 비즈니스 로직과 데이터 접근 계층간의 의존성이 있다. 비즈 로직 구현이 트랜잭션 스크립트, 엑티브 레코드인 경우 적합한 아키텍처이다. 그렇지만, 결국 데이터 처리에 비지니스 로직이 점점 몰리게..

Guard는 허용된 유저가 아니면, 요청 자체를 막아버리는 것이다. 서버의 리소스를 허용된 유저가 아니면 사용할 수 없도록 하는 것이고, 서버의 자원 낭비를 막을수 있게 된다. decorator 문법을 사용하고, ts에서 실험기능에 포험되어있다고한다. 일단 가이드로 통용되고있는 구현체를 구현해보자 Guard의 기본로직은 아래와 같다. 1. 회원가입 2. 사용자 정보와 대응하는 jwt생성 3. 사용자가 서버에 요청을 보낼때 Header에 jwt를 담아서 보낸다. 4. Guard에서 확인 5. 유효한 값이면 통과, 아니면 에러를 일으킨다. 1. Authorization guard 사용자 인증은 가드의 대표적인 예시이다. AuthGuard는 사용자의 헤더에 특정 토근이 제대로 들어있는지를 확인하는 것이다. G..

axon framework는 axon server와 axon framework가 있다. axon framework 에서 이벤트 소싱이 발생될 때, axon-server가 아닌, 카프카나 외부 모듈을 사용할 수 있는데, 우선은 해당 axon-framework와, axon-sever를 통해서 진행해보자 axon framework의 아키텍처는 아래와 같다. 대게는 데이터를 변경하는 Command Event와, 조회용 Query에 대한 저장소가 분리 되어있다. 커맨드를 날리게 되면, 해당 Command Handling Component가 받아서, 처리를 한다. 처리 중에 외부 저장소에 영속이 필요한 경우 persist 작업을 거치고, 이러한 변화에 대한 이벤트를 이벤트 핸들링 Component가 받아 처리하는 ..

우선 게시물에 대한 Entity를 아래와 같이 바꿨다. import { BaseEntity, Column, Entity, OneToMany, PrimaryGeneratedColumn, } from 'typeorm'; import { Record } from './record.entity'; @Entity() export class Board extends BaseEntity { @PrimaryGeneratedColumn() uid: number; @Column() title: string; @Column({ unique: true }) userId: string; @Column() nickname: string; @Column() password: string; } board.repository.ts i..

일단 가볍게 이미지를 받아준다. docker pull mariadb 그리고, 포트랑 이름, 볼륨 마운트 정보를 넘겨서 커맨드를 입력한다. 사용자,포트,데이터베이스를 한번에 생성한다. docker run -d --name mydb -p 3306:3306 --env=MYSQL_ROOT_PASSWORD=1234 --env=MYSQL_USER=admin --env=MYSQL_PASSWORD=admin --env=MYSQL_DATABASE=test mariadb 도커 프로세스를 확인한다. 끝 이제 NestJS쪽에서 디비 연동 및 세팅을 진행해보자. 일단. TypeOrm을 사용하기 위해서, 관련 라이브러리를 설치해줘야 한다. npm install --save @nestjs/typeorm typeorm mysql2 ..

자바랑 살짝 비슷하게 생겼는데 커스텀 파이프는 PipeTranform을 구현해야 하고, 하위 transform()메소드를 구현해야한다 import { ArgumentMetadata, PipeTransform } from "@nestjs/common"; export class BoardStatusValidationPipe implements PipeTransform { transform(value: any, metadata: ArgumentMetadata) { console.log(value) console.log(metadata) return value; } } @Patch('/:id/status') updateBoardStatus( @Body('status',BoardStatusValidationPip..

그냥 뭐.. 정의 된 예외를 던져주면된다. 스프링이랑 이건 뭐 거의 동일하다. getBoardById(id: string) : Board{ const board = this.boards.find((board) => board.id == id); if(!board) throw new NotFoundException(); return board } throw new NotFoundException("Not Found Exception"); 이렇게 하면 Exception message까지 가능하다. 이렇게 확인까지 가능하다. 생각보다 간편하다. ExceptionHandler 기능을 하는것도 있을것같은데...무튼 그렇다. ExceptionHandler라기 보다는, 글로벌하기 파이프를 연결 하면.. 가능할 것같다..

드디어 NestJS의 개념에 대한 공부이다. NestJs에서 Injectable() 데코레이터로 달린 클래스를 의미한다. 파이프는 data transformation과 data validation을 위해서 사용된다. 파이프는 컨트롤러 경로처리기에 의해 처리되는 인수에 대해 작동된다. 파이프가 없으면 바로 핸들러로 가게된다. 근데, 만약에 파이프가 있다면? 데이터에 대한 체크와 유효성 체크를 하고 나서 핸들러로 보내게된다. 스프링으로 치면... AOP나 필터라고 생각하면된다. (백엔드는 다 비슷하구나..) 자, 그러면 어떻게 구현을 하고 어떻게 동작하는지 한번 해보자 특정 메소드 별로 데코레이터를 선언해서 사용할 수 있다. 파라미터단위로 데코레이터를 선언해서 사용할 수도있다. 글로벌 레벨의 파이프도 있다...