아키텍처패턴

1. 프로그래머스
2. 도메인 Domain
3. 아키텍처 패턴 Architecture Pattern

공부하면 느낀 점
참조한 사이트

1. 프로그래머스

문자열 겹쳐쓰기

어떻게 lloWorl를 붙여서 lloWorld 를 만들라는건지 알 수 없어서 넘어갔다. 최신 문제던데 오류인가?

부분 문자열

function solution(str1, str2) {
    var answer = 0;
    if (str2.split(str1).length > 1){
        return 1
    } else {
        return 0
    }
    return answer;
}

다른 사람의 풀이

const solution = (str1, str2) => str2.includes(str1) ? 1 : 0;

function solution(str1, str2) {
    return str2.indexOf(str1) > -1 ? 1 : 0
}

includes 나 indexOf 도 고려해봐야겠다.

• inclues
  배열이 특정 요소를 포함하고 있는지를 판별 후 boolean을 반환
• indexof
  배열에서 지정된 요소를 찾을 수 있는 첫 인덱스를 반환, 없을시 -1 을 반환

배열의 평균값

뭔가 한번에 하는 함수가 있을 것같지만 모르므로... for문을 돌리자

function solution(numbers) {
    var answer = 0;
    let sumOfNumbers = numbers[0];
    for (let i = 1 ; i < numbers.length ; i++){
        sumOfNumbers += numbers[i];
    }
    answer = sumOfNumbers/numbers.length
    return answer;
}

원래는 i-1 + i 형식으로 풀려다가 이렇게되면 중복되어서 더하기가 될것같다고 판단되어서 코드를 조금 수정했다.
그결과 조금 이상한 모양이 됐는데

다른 사람들의 풀이를 보니 한번에 하는 함수는 없는 것같다.

if 문을 컨트롤러에 넣지 말 것
req res 만

crud 레포지토리

정보가공, 암호화 try catch 서비스

2. 도메인 Domain

프로세스가 동작하거나 지원하는 활동 자체를 말한다.

개발자 대부분은 비즈니스 프로세스를 개선/자동화 하기 위해 일한다. 실제로 하는 일에 따라서 다른 분야를 지칭할 수 있다.

도메인은 하위 도메인으로 나뉘어진다.

도메인 모델 Domain Dodel 유용한 특성을 포함하는 프로세스의 현상이나 map을 의미한다. 도메인 모델은 비즈니스를 수행할 사람이 자신의 일에 대해 가지고 있는 인식이다.

1. 엔티티 Entity
2. 값 개체 Value Objdect

1. 엔티티
   엔티티를 기준으로 테이블이 생성되고 DB스키마가 변경된다.
   예) synchronize 로 DB와 모델을 매핑한 경우 모델을 기준으로 테이블이 생성된다. 즉, 모델이 엔티티이다.

엔티티를 요청 / 응답 값으로 전달하는 클래스로 사용해서는 안된다.
엔티티의 내부 속성이 바뀌더라도 동일한 엔티티로 남는다.
엔티티를 유일하게 식별하는 요소를 정의해야한다.

3. 아키텍처 패턴 Architecture Pattern

• 소프트웨어의 구조를 구성하기 위한 가장 기본적인 토대
  각각의 시스템들과, 그 역학이 정의되어 있고, 여러 시스템 사이의 관계, 규칙등이 포함되어있다.

이미 검증된 구조로 개발을 한다.

도메인이 복잡할 수록 모델이나 코드를 더 쉽게 변경할 수 있다.

• 저장소 패턴 Repository pattern
  영속적인 저장소에 대한 추상화를 위한 패턴
• 서비스 계층 패턴 Service layer pattern
  usecase의 시작과 끝을 명확하게 정의하기 위한 패턴
• 작업단위패턴 Unit of work pattern
  원자적인 연산을 제공하는 패턴
• 애그리게이트 패턴 Aggregate pattern
  데이터 정합성을 강화하기 위한 패턴

아키텍처 패턴을 고르기전에 고민할 것
1. 도입시 이익과 비용에 대한 확실한 이유가 있어야한다.
2. 장단점을 명확히 인지해야한다.
3. 시간과 노력을 많이 투자해야하므로, 그만큼 복잡한 어플리케이션, 도메인인 경우에만 도입해야한다.

계층형 아키텍처 패턴 Layered Architecture Pattern

가장 대중적이고, 저비용인 표준형 아키텍처

계층을 분리해서 유지하고, 각 계층이 자신의 바로 아래 계층에만 의존하도록 만드는 것이다.

상위 계층은 하위계층을 이용할 수 있지만, 하위계층은 상위 계층에 대해 알 수 없어야한다.

1. 프레젠테이션 계층 Presentation Layer
2. 비즈니스 로직 계층 Business Logic Layer
3. 데이터 엑세스 계층 Data Access Layer
   = Persistence Layer

• 계층별로 아키텍처를 분리했을 경우의 장점

1. 관심사를 분리하여, 코드의 역할을 명확히 인지할 수 있다.
2. 각 계층별 의존성이 낮아 모듈교체가 쉽다.
3. 각 계층별로 단위 테스트 Unit Test 를 작성할 수 있어 테스트 코드를 용이하게 구성할 수 있다.

3계층 아키텍처 3-Layered Architecture

• 컨트롤러 Controller
  클라이언트의 요청을 받고, 서버에서 처리된 응답을 넘겨준다.
• 서비스 Service
  아키텍처의 가장 핵심적인 비즈니스 로직이 수행된다.
• 레파지토리 Repository
  DB와 맞닿은 어플리케이션의 가장 안쪽 부분이다.
  실제 데이터베이스의 데이터를 사용하는 계층이다.

흐름도
1. Client가 request를 보낸다.
2. Request의 알맞은 url에 해당하는 controller가 수신 받는다.
3. Controller는 requset를 처리하기 위해 service를 호출한다.
4. Service는 필요한 데이터를 가져오기 위해 repository에 데이터를 요청한다,.
5. Repository가 DB에서 가져온 명확한 결과값(=데이터)를 service에 보낸다.
6. Service가 repository에서 온 정보를 가공한다.
7. Service가 가공된 정보 response를 client에 전달한다.

공부하면 느낀 점

1. 어제 공부한 문자열의 숫자화와 마찬가지로, 문자열을 판단하는 것도 정말 아 다르고 어 다르다는 걸 느꼈다.
2. 아키텍처 패턴은 처음부터 제대로 설계하고 써야하는 것인것같다. 간단한 프로젝트라면 굳이 할 필요 없고, 복잡한 프로젝트라면 잘못된 것을 쓰면 고생해서 오히려 더 나쁜 코드를 만들 것같다.

참조한 사이트

프로그래머스
indexOf / includes