The Clean Code

Writing code is like making a new life. Life must be adaptable to change in environment. You must be responsible that the code will be vigorous in the future even after it leaves your hand.

http://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html

Clean Code and the SOLID principal

Abstraction

Single Responsibility

Open and Closed

Clean Architecture

예전부터 관심이 많았고 도전해보고 싶었따.

뼈대가 있는 프로젝트에서 책임을 분리하면서 개발을 용이하게 한다.

요청하는 폴더를 provider

api provider는 두가지. base는 공통된 코드를 base로 먼저 정의.

http요청에는 중복 코드가 생기는데 중복을 먼저 base로 저장해준다. 그걸 상속해서 특정 api 요청을 만든다.

response는 그 이외에 사용되는

DI : dependency injection

a가 b에 의존한다는 a가 b를 사용한다. 그 중 생성자 주입은 constructor. 생성자에 주입할수있고 게터 세터에 주입할 수 있는데 생성자에 넣는것이 좋다.

인터페이스란 ? 명세. 변수에 대한 메서드, 메서드에 대한 명세가 있다.

왜 굳이 명세를 따로 만들어야되는가? 의존성 역전 원칙 DIP. 핵심은 책임을 나누는 것이다. 근데 서비스가 도메인인데 서비스가 레포지토리를 바로 참조하면 명세만 알면 되는게 아니라

value-object는 우리가 정의하는게 아닌 엔티티.

useCase에서 논리적인 단위를 정의한다. 논리적인 단위는 행위의 단위고, 행위를 하기위해선 다양한 도구들이 필요하다.

UseCase에서 행위를 한다.

Data Access Object : Repository. 데이터와 도메인 레이어 사이에서 사용을 할 수 있게 중간에서 다리역할을 한다.

MVC 자바

JAVA 에서는 데이터가 DB 도메

컨트롤러가 프레젠테이션 도메인이 서비스 DAO가 레포지토리.

DAO에서 쿼리를 날려서 갖고오는것이다.

데이터 프름

백엔드 -> http(api) -> repository가 getallmovies로 무비 데이터를 리턴한다.

http는 api로 백엔드에서 갖고오는것.

근데 백엔드랑 요청을 할때는 레포지터리가 아마 필요없을것이다.

UseCase에서는 작업을 한다. 모델이 entity다. 무비라는 객체. 도메인 레이어의 엔테테는 이런 모델(엔티티)를 정의한다. 서비스의 가장 원초적이 데이터이자 핵심이다. 저수준일수록 임포트가 없다.

component vs containers : 컴퍼넌트가 기본. 논맂가 들어가면 컨테이너

리덕스 대신에 context를 사용한다. 리덕스는 러닝커브가 있어서 일단은 컨텍스트를 하고 나중에 리덕스를 도입한다.

yarn create react-app my-app --template typescript

test는 생략.

swagger : backend에서 만들어주는 파일.