Node.js 심화 - 5

__________________________________________________

 

1-13  쇼핑몰 프로젝트 코드 분리하기

 

=>  < 3.3객체지향 04 >

3.3 객체지향 Goal : 객체지향이란 무엇인지 이해하고 SOLID 원칙을 이용하여 코드를 작성할 수 있다.

 

 

쇼핑몰 프로젝트의 app.js에 작성했던 코드를 여러개의 파일로 나눠서 분리시켜 보자.

 

폴더 : kimminsoo -> sparta -> node_js -> learning -> third_step -> shop-project-for-socket

 

 

 

— 코드를 분리하는게 왜 필요할까 —

=>

1. 가독성 향상: 코드를 분리하면서 추상화가 자연스럽게 되기 때문에 코드를 읽기가 훨씬 수월해 진다.

2. 관리(유지보수)의 용이: 어떤 함수가 어떤 역할을 갖는지 비교적 쉽게 파악할 수 있다.

 

 

“ 추상화 “

 

 

 

 

 

 

__________________________________________________

 

1-14  소켓 연결 코드 분리하기

 

=>  < 3.3객체지향 05 >

3.3 객체지향 Goal : 객체지향이란 무엇인지 이해하고 SOLID 원칙을 이용하여 코드를 작성할 수 있다.

 

 

“ 추상화 “ : 코드를 이해하기 쉽게 함수로 분리하기

“ 기능의 역할 “ : 특정 역할을 하는 코드들은 묶어서 파일로 분리하기

 

 

 

——

< server.js >

 

 

const http = require("./app"); // app 을 가져오기 위해 require 을 실행하며 app.js 안의 모든 코드들을 한 번 실행해.

require("./socket");    // require 로 socket.js 를 불러오면 해당 Js를 한 번 쫙 읽어.

                        // 따라서 socket.js 의 const io = socketIo(http); 도 알아서 잘 선언한다고.

 

http.listen(8080, () => {

    console.log("서버가 요청을 받을 준비가 됐어요");

});

——

 

 

 

——

< socket.js >

 

const socketIo = require("socket.io");

const http = require("./app")   

const io = socketIo(http);

 

io.on("connection", (socket) => { // 현재 접속한 사용자의 정보는 sock 변수에 할당된다.

    console.log("새로운 소켓이 연결되었습니다.");

    const { watchBuying, watchByeBye } = initSocket(socket);    

            // initSocket 을 가져오려 하는 순간 해당 함수를 한 번 쫙 읽어봐.

            // 따라서 watchBuying() 이라고 바로 아래에서 함수를 실행해도 watchEvent, sendMessageAll 이 작동하는 것이고.

    // 이 부분이 좀 낯설게 느껴졌었어… 여태까지 항상 return 으로 값만 가져와서 그랬나봐. 여기서는 실행문이잖아.

 

    watchBuying();

    watchByeBye();

})

  

 

const initSocket = (socket) => {

 

    // socket.on 을 대신해서, 어떤 역할을 하는지 추상화 한 함수.

    const watchEvent = (eventName, func) => {

        socket.on(eventName, func);

    } 

 

    // 현재 접속한 모든 클라이언트 들에게 메세지를 전송하는 구나 라고 이해할 수 있는 함수.

    const sendMessageAll = (eventName, data) => {

        io.emit(eventName, data)

    };

 

    return {

        watchBuying: () => {

            watchEvent("BUY", (data) => {  // 클라이언트가 emit으로 "BUY" 이벤트를 발생시켜서 데이터를 전송한다?

                // 서버측에선 미리 socket.on("BUY") 로 정의해 둔 로직을 통해서 해당 이벤트를 수신한다.

                const emitDate = {

                nickname: data.nickname,

                goodsId: data.goodsId,

                goodsName: data.goodsName,

                date: new Date().toISOString

                }

                sendMessageAll("BUY_GOODS", emitDate); // 전체 방송

            });

        },

        watchByeBye: () => {

            watchEvent("disconnect", () => {

                console.log(socket.id, " 사용자의 연결이 끊어졌습니다."); // disconnect 이벤트를 발생시킨 사용자의 id 를 호출.

            });

        }

    }

 

}

——

=> 이제는 node server.js 로 서버를 실행시켜야 해.

 

 

 

 

 

 

 

__________________________________________________

 

1-15  도메인

 

=>  < 3.4 Layered Architecture Pattern 01 >

3.4 Layered Architecture Pattern Goal : 아키텍처 패턴에 대해 이해하고 계층형 아키텍처 패턴을 도입해 express를 구현할 수 있다.

 

 

 

— 도메인 —

 

개발자 대부분은 비즈니스 프로세스를 개선하거나 자동화하기 위해 일한다. 

도메인은 이런 프로세스가 지원하는 활동을 의미한다.

 

ex) 가구 판매 회사의 도메인은 구매 및 조달, 제품 설계, 물류 및 배달 등 다른 분야를 뜻할 수 있어.

이러한 분야들 에서의 주 업무를 이루기 위해서, 여러 지원 프로세스들이 필요 하겠지.

 

예를 들어 제품 설계라면, 어떤 식으로 만들고, 어떤 식으로 구성이 되고, 어떤 식으로 조립을 해야 하는가에 대한

체계적인 정보를 제공하는 프로세스가 있어야 하겠지. 

 

 

 

구체적인 도메인의 예시.

 

=> 개발자 입장에서 온라인 서점을 구현해야 할 소프트웨어의 대상이 된다. 즉 해결하고자 할 문제 그 자체를 도메인이라 부를 수 있어.

온라인 서점 = 소프트웨어로 해결하고자 하는 문제의 영역 = 도메인 (Domain)

 

한 도메인은 다시 하위 도메인으로 나눌 수 있어.

도메인 구성 : 주문, 회원, 혜택, 결제, 배송, 정산, 카탈로그, 리뷰

하위 도메인은 다른 하위 도메인과 연동하여 완전한 기능을 제공한다.

ex) 고객 → 물건 주문 → 결제 → 배송 → 혜택 제공

 

하위 도메인을 어떻게 구성할 지 여부는 상황에 따라 달라진다.

예를 들어 B2B냐, B2C냐.

 

 

 

 

— 도메인 모델 —

 

도메인 모델은 유용한 특성을 포함하는 프로세스나 현상의 지도를 뜻한다.

도메인 모델은 비지니스를 수행할 사람이 자신의 비지니스에 대해 마음속에 가지고 있는 지도와 같아.

=>

도메인이란 프로세스가 지원하는 활동 자체를 가리키는 용어 였어.

도메인 모델은, 그런 활동 자체를 실제로 설계하는 과정이나 설계가 되어 있는 결과의 형태라고 말할 수 있어.

 

즉, 도메인 모델이란 특정 도메인을 개념적으로 정리한 모델.

실제로 ‘프로세스’ 를 만들기 위해 개발자가 수행할 비지니스 로직에 대한 내용이나,

아니면 도메인을 실제로 어떤 식으로 구현할 지에 대한 설계도.

 

도메인 모델은 사용할 개체를 기억하기 쉬운 이름(식별자)을 부여해 대상을 쉽게 공유할 수 있게 한다.

 

 

**

만약 누군가가 저희에게 공을 던진다면 우리는 무의식적으로 이 공의 움직임을 예측해 회피하려 하겠지.

=> 우리들의 머릿속에 이미 공간상 물체가 움직이는 방식에 대한 모델이 있어서 움직임을 무의식적으로 예측할 수 있어.

즉, 어떤 식으로 구성되고 어떤 식으로 움직일 지에 대한 대략적인 생각 자체가 모델.

 

도메인 모델링 (Domain Modeling)의 종류

1. 엔티티 (Entity)
2. 값 객체 (Value object)
3. 도메인 서비스 (Domain service)

 

 

 

 

 

 

— 엔티티 (Entity) —

 

1.

실제 DB 테이블과 연관되어 있는 핵심 클래스이고, 엔티티를 기준으로 테이블이 생성되고 DB 스키마가 변경된다.

=> sequelize 의 models 같은 느낌.

 

2.

엔티티를 요청(Request)이나 응답값(Response)으로 전달하는 클래스로 사용하면 안된다.

=> 이 부분은 또 mybatis 를 이야기 하는 것 같기도.

 

3.

엔티티 내부의 속성이 변경되더라도 여전히 동일한 엔티티로 남아있다.

=> 예를 들어 내가 Users 라는 엔티티를 만들고,

엔티티 안에 닉네임, 패스워드, 나이, 이메일 등 여러 속성을 준다고 쳐.

설령 속성 내부에 있는 값이 만약에 변경된다 하더라도, 여전히 똑같이 Users 라는 엔티티에 속해 있는 것.

 

4.

엔티티는 시간에 따라 변하는 속성이 포함될 수 있다.

 

5.

어떤 요소가 엔티티를 유일하게 식별 하는지 정의하는 것 또한 중요하다.

=> 즉 primary key 를 뜻한다. 혹은 유니크 값.