DevBoi

각기 다른 도메인들은 독립적으로 발전 할 수도 있지만, 상호작용해야한다. 각 접점이 존재한다. 이를 contract라고 한다. - 협력형 패턴 그룹 - 사용자,제공자 그룹 - 분리형 노선 결재자와 수취자에 대한 개념을 모델링을 했다고 하면, 각각 다른 도메인에 있어, 다른 위치에 있지만, 의미는 같다. 이를 같은 의미인지 통역해주는 과정이 컨텍스트 매핑이다. * 협력형 패턴 * 공유 영역 공유 영역이라고 하면, 라이브러리 영역을 공통으로 포함을 해서 배포를 각각 A,B를 한다. 마이크로 서비스할때는 공유 영역을 최소로 하는것이 중요하다. 대부분의 패턴은 공급자,소비자 패턴을 쓴다고 한다. 정보를 받을때 공급자 입장에서는 upstream, 소비자 입장에서는 downstream이라고한다. 상류의 모델에서, ..

마이크로 서비스를 식별할때 대중적으로 쓰이는 방법이다. 비지니스 도메인 : 기업의 주요활동영역, 회사가 제공하는 서비스 (sub domain) 하위 도메인: 비즈니스 활동의 세분화된 영역, 제공하는 서비스 단위 쉽게 얘기하면, 도메인과 서브 도메인으로 분류할 수 있다. 하위 도메인의 개념 하위 도메인은 도메인을 표현하는 영역이다. * 핵심 -회사가 경쟁업체와 다르게 수행하고 있는 것 -복잡성 높지만 BIz경쟁력 제공 * 일반 - 모든회사가 같은 방식으로 수행하는 비지니스 활동 - 복잡하고 구현하기 어려우나, 경쟁력을 제공하지는 않음, 알려진 영역 - 인증,권한 * 지원 - 회사 비지니스 지원활동 - 기능간단,어떠한 경쟁우위 제공하지 않음 - CRUD, ETL 유비쿼터스 언어 도메인 주도 설계에서는 도메인..

모놀리스 시스템이다. 3티어로, 클라이언트는 서버를 통해, 데이터 베이스를 호출하고 서버는 한덩어리로 구성되어있다. 레거시 적인 시스템의 문제는 있다. -한꺼번에 수정 배포되어야 해서, 다운타임이 전체적으로 존재한다. -하나 실패되면, 모두 실패된다. -단일 프로세스를 실행한다. -애플리케이션이 한덩어라로 구현이된다는 것 자체가 문제이다. -스케일아웃에 대한 진행이 전체적으로 다 진행이 되어야 한다. 또한 저장소마다 격리가 되어있기 때문에, 저장소별 스케일업이 가능하며, 각 저장소는 API에 대해 캡슐화된 장점이 있다. 또한 뭐.. 여러가지 언어로 API 및 저장소를 캡슐화 할수 있다는 것이 좋다.

*하드 링크 : 특정 파일 , 디렉토리에 접근을 쉽게 할 수 있도록 하는 방법 *심볼릭 링크는 : 윈도우에서 바로가기와 동일하게 생각하면 된다. 한번 거쳐서 가르키는 것이다. 즉 간접적으로, 하드링크를 가르키는것이다. 하드 링크 만드는 법 ln ln test.txt test_1.txt 이렇게 하면, 심볼릭 링크로 똑같은 test_1.txt가 생성이되고 이는 test.txt를 참조한다. test.txt파일을 변경해도 동일하게 test_1.txt를 보면 변경된 내용을 확인 할 수 있다. 복사를 해서, 파일이 달라지면? cp 복사를 하면 당연히 원본을 바꾸어도, 반영되어 보이지 않는다. 심볼릭 링크를 만들어보자 ln -s 이렇게 하면, 생성이되고 ls -al로 확인이 가능하다. 또한 원본파일을 바꾸게 되면, ..

기초를 알긴하지만, 그래도 정리하면서 다시 기초를 해보자 기본 구조 commandname option input 명령어들 which echo (명령어 위치 알수 있음) cat > output.txt (output.txt로 입력이 된 파일이 생성됨, 즉 cat해서 입력한 내용이 output으로 출력됨) cat >> output.txt (기존 내용이 사라지지않고, 추가가 된다.) ls > list.txt (나오는 내용이 파일로 저장됨) find find -name find /etc -iname ssh_config find /etc -iname *ssh_config* iname을 하는 이유는,대소문자 구분없이 검색을 하기 위함이고 *ssh_config*는 와일드카드로, 해당 문자열이 포함된 파일을 전부 찾게 ..

kubectl 명령어 모음이다. 적어두고 유용하게 ...두고두고 사용하자 설명이 필요한 것만 설명을 적어놓겠다. kubectl get all (pods,svc,deployments) kubectl get ing kubectl config view kubectl get pods -o wide (더 많은 내용 조회) kubectl get pod my-pod -o yaml ( 파드의 yaml조회) kubectl get nodes kubectl get -o jsonpath={..spec.containers[*].name}; echo (특정 파드의 컨테이너 이름 조회) 1. kubectl get namespaces 2. kubectl config set-context --current --namespace -> ..

오늘은 AWS의 k8s 서비스인 EKS를 로컬에 세팅하는 방법에 대해서 알아볼 것이다. 일단 나의 환경은 윈도우 + WSL + AWS이다. 물론, 인스턴스와 EKS세팅은 별도 포스팅에서 다루고 오늘은 회사에 입사해서 EKS를 쓰고있는데, 내 로컬에서 쓸 수 있도록 하는 것이다. 기존에는 AWS에 직접 접속을 해서 커맨드를 날렸지만 EKS는 로컬에서 kubectl을 해도, 해당 aws의 k8s가 응답을 준다. 이게 어떻게 가능할지는 아래 방법을 따라해보자 총 3가지가 필요하다 aws cli aws confiure kubectl 설치 1. aws cli 설치 aws는 실시간으로 변경되기 때문에 우선 아래 공식문서를 확인한다. https://docs.aws.amazon.com/ko_kr/cli/v1/userg..

테스트 컨테이너와 Spock를 이용해서 테스트 환경을 구축하다가 DB autocommit을 끄는것에 대해서 공부를 해보려고했다. (팀에 고수분이 의견을 주셨다) 1.Autocommit은 무엇일까? 하나의 트랜잭션은 commit이나 rollback을 만나면 종료된다. 트랜잭션의 성질은 ACID를 따르는데 (이건 모르면 직접 찾아보시길) 1,2,3작업이 있다고 가정 한 트랜잭션에 있다면? 1번 작업 후 2번 작업중 이슈가 생기면? 1번 작업은 commit이 될까? 같은 트랜잭션 이라면 2번이 롤백되면서 1번도 롤백된다. 다만 오토 커밋이라고하면 commit을 따로 날려주지않아도 자동으로 커밋되는것이다. 즉 하나의 트랜잭션 내에 여러가지의 쿼리가 있다고 하더라도, 무용지물로 그냥 다 반영 되는것이다. 쉽게 얘..

사용을 위한 기본구성 1. JpaFactory package com.practice.demo.config; import com.querydsl.jpa.impl.JPAQueryFactory; import org.springframework.beans.factory.annotation.Autowired; import org.springframework.context.annotation.Bean; import org.springframework.context.annotation.Configuration; import javax.persistence.EntityManager; @Configuration public class JpaFactory { @Autowired EntityManager em; @Bean ..

Rebase를 해보자 master, develop 브랜치 두개로, develop에 작업이 추가되었다고 가정해보자 master 에서 개발중인 사람은 이런 상황이다. 이제 master 기준에서 rebase를 해보자 master에서 메소드를 하나 더 추가했고, rebase를 하면 머지와 동일하게 사용할 수 있다. 그럼 머지랑 무슨 차이일까? 사실 예시가 잘못되었는데 만약에 master의 량이 상당해졌고, develop에서 작업하다가 머지하면 문제가 생길것같다. 그럴경우 develop 개발자가 리베이스를 하고, master작업분을 받아 작업을 한뒤 푸쉬하면 된다. 즉 머지가 내 껄 다른 브랜치에 붓는다고 한다면 재배치는, 다른걸 자기껄로 가져와서 미리 붓는다고 이해하면된다.