일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |
- SBT
- 제주
- Spring
- Domain Driven Design
- DDD
- design pattern
- hadoop
- apache storm
- 스프링 배치
- intellij
- Java
- scala
- Hbase
- Angular2
- Clean Code
- Spring Boot
- hibernate
- docker
- Spring Batch
- Storm
- spark
- elasticsearch
- hdfs
- 도메인주도설계
- 엘라스틱서치
- Spring XD
- Gradle
- elastic search
- Linux
- nginx
- Today
- Total
목록분류 전체보기 (236)
욱'S 노트
Quickstart Docker Engine 이 퀵스타트는 도커 엔진이 동작하도록 설치가 되어있다고 가정한다. 엔진이 설치되었는지를 확인하기 위해 다음과 같은 명령을 수행해보자. $ docker infoContainers: 12Images: 14Storage Driver: aufs Root Dir: /mnt/sda1/var/lib/docker/aufs Backing Filesystem: extfs Dirs: 38 Dirperm1 Supported: trueExecution Driver: native-0.2Logging Driver: json-fileKernel Version: 4.0.9-boot2dockerOperating System: Boot2Docker 1.8.2 (TCL 6.4); master :..
이번 섹션에서는 우리가 생성한 리파지토리에 docker-whale 이미지를 태그하고 푸쉬 해보겠다. 이것이 끝나면 우리는 리파지토리로 부터 새로운 이미지를 풀해보겠다. Step 1: Tag and push the image 아직 터미널을 열지 않았다면 터미널을 열어라. 터미널이 오픈되면 당신이 현재 가지고 있는 도커 이미지를 확인해보자. docker images라고 명령을 수행해보자. $ docker imagesREPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZEhello-world latest af340544ed62 5 months ago 960 Bdocker/whalesay latest fb434121fc77 8 months ago 247 MB docker-whalesay ..
당신이 어떤 좋은 것을 만들었다면 그것을 공유할 수 있다. 이번 섹션에서는 우리는 공유를 해볼것이다. Docker Hub account가 필요할 것이다. 그러면 당신의 이미지를 푸쉬해서 다른 사람들이 도커에서 실행할 때 사용할 수 있게 할 수 있다. Step 1: 계정 만들기 브라우저에서 도커허브 singup 페이지로 이동하자. 다음과 같은 페이지가 출력될 것이다. singup 페이지에 형식을 채우자. 도커 허브는 무료이다. 도커는 이름, 패스워드 이메일 주소가 필요하다. Signup을 누르자. 도커허브 웰컴페이지가 출력될 것이다. Step 2: 이메일 검증 및 리파지토리 추가하기 어떤것을 허브에 공유하기 전에 이메일이 맞는지 확인할 필요가 있다. 이메일 받은편지함에 가보자. 이메일의 제목이 다음과 같은..
Intention-revealing interface 개발자가 컴포넌트를 사용하기 위해 컴포넌트의 구현 세부사항을 고려해야 한다면 캡슐화의 가치가 사라진다. 도메인 내의 개념을 클래스나 메서드 형태로 명확하게 모델링하여 인터페이스로 전달해야 한다. 주의할 점은 수행 방법에 관해서는 언급하지 말고 오직 결과와 목적만을 표현하도록 클래스와 연산의 이름을 부여해야 한다. Side-effect-free function CQRS가 중요하다. comand-query responsibility segregation. 즉 명령과 질의는 엄격하게 분리되어야 한다는 것을 의미한다. 다수의 규칙에 따라 상호작용하거나 여러가지 계산이 조합되면 극도로 예측하기가 힘들어진다. 이 의미는 연산을 호출하는 개발자가 연산 자체의 구현..
모든 종류의 어플리케이션에는 규칙을 검사하는 Boolean 테스트 메서드가 있다. 규칙이 단순하다면 invoice.isOverdue와 같이 규칙을 검사하면 된다. 그러나 종종 업무규칙이 엔티티나 VO가 맡고 있는 책임에 맞지 않고 규칙의 다양성과 조합이 도메인 객체의 기본 의미를 압도할 때가 있다. 만약 규칙을 도메인 계층에서 분리를 한다면 예를 들어 응용계층으로 내린다면 상황이 더 악화된다. Specification은 다른 객체에 대한 제약조건을 기술하며, 제약조건은 존재할 수도 존재하지 않을수도 있다. 특정한 목적을 위해 술어와 유사한 명시적인 VO가 바로 SPECIFICATION이다. public class RouteSpecification extends AbstractSpecification im..
모든 객체는 생명주기가 있다. 일반적으로 객체는 생성자를 호출해서 만들어진 다음 가비지 컬렉터에서 삭제된다. 그러나 엔티티의 경우는 더욱 오래 지속되며, 메모리안에서만 시간을 보내지 않는다. 그리고 각 엔티티들은 상호의존성을 갖는다. 이러한 객체들을 관리하는데 실패한다면 도메인주도개발을 시도하는 것에 쉽게 좌절될 수 있다. AGGREGATE 어그리게이트는 우리가 데이터 변경의 단위로 다루는 연관 객체의 묶음을 말한다. 각 AGGREGATE는 루트와 바운더리가 있다. 루트는 단 하나만 존재하며 외부에서 객체를 참조할때는 어그리게이트 루트만을 통해서 이루어져야만 한다. 또한 삭제와 변경도 어그리게이트 루트를 통해서만 이루어져야 한다. 외부객체는 어그리게이트 루트만 접근할 수 있게 하고 내부만 감춰야만 한다...
엔티티 VS VO 어떠한 객체가 상태를 가진다면 엔티티와 VO라고 생각할 수 있다. 둘의 차이점은 연속성(continuity)와 식별성(identity)를 가지는 가에 있다. 연속성과 식별성이 필요하다면 엔티티이다. 여기에서 중요한 점이 영속성이 엔티티와 VO을 나누는 개념은 아니다. VO도 엔티티와 함께 데이터베이스에 저장될 수 있다. 연관관계 각각의 엔티티는 탐색 가능한 연관관계를 가질 수가 있다. 일대일, 일대다, 다대일, 다대다이다. 사실 현실 세계의 모든 엔티티들은 양방향 디펜더시를 가진다. 하지만 연관관계를 쉽게 다루기 위해선 단방향으로 관계를 단순화할 필요가 있다. -> 범균님은 무조건 양방향 디펜던시는 제거해야 한다고 한다. 탐색방향을 부여하고, 한정자를 추가하고 중요하지 않는 연관관계는 ..
Layered Architecture 복잡한 소프트웨어를 만들 경우 관심사의 분리(seperation of concern)가 필요하여 이로써 격리된 상태에 있는 각 설계 요소에 집중 할 수 있다. 사용자 인터페이스 - 일반적인 UI. 간혹 사람이 아닌 컴퓨터 시스템이 외부 행위자가 되기도 함(스케쥴러)응용 계층 - 얇게 유지되어야 한다. 업무 규칙이나 지식이 포함되지 않으며 도메인간 상호작용만이 존재하며 도메인 객체에 작업을 위임. 작업에 대한 진행상황만을 상태로 가짐도메인 계층 - 업무 개념 및 업무 상황, 규칙에 관한 정보를 표현 기술적인 세부사항은 인프라스트럭처에 위임인프라스트럭처 계층 - 상위 계층을 지원하는 일반화된 기술적 기능. - 예) 메시지 전송. 도메인 영속화 안티패턴 - 스마트 UI, ..
어떤 방법론에서는 분석 모델(analysis model)을 지지하였다. 분석모델에서는 분석과 설계가 섞이면 혼란만 초래한다고 주장하였다. 그러나 이러한 모델의 단점은 초기의 지식 탐구가 코딩이 시작되기 시기 대부분의 지식탐구가 사라진다는 것이다. 모델주도설계에서는 분석과 설계 모델을 나누지 않는다. 이 경우 유의할 점은 기술적 고려사항이 분석에 심각하게 침해되어서는 안된다. 또한 모델이 구현에 너무 비현실적이라면 새로운 모델을 찾아야 한다. 모델링과 설계가 점진적이고 반복적으로 이루어져야 한다. 모델링 패러다임과 도구 지원 모델과 설계가 밀접한 대응을 가능하게하려면 모델의 개념에 직접적으로 대응되는 것을 만들어낼수 있는 소프트웨어 도구가 필요하다. 객체지향 프로그래밍이 가장 효과적인 도구이다. 이는 절차..
도메인 모델은 공통언어의 핵심이자 도메인에 대한 통찰력을 반영하는 용어와 관계로 표현된다. 모델기반의 의사소통으로 꼭 UML을 사용해야 하는 것은 아니다. 어떠한 의사소통 수단을 사용해도 무방하며 형식에 얽매이지않는 다이어그램이나 텍스트문서도 가능하다. 또한 코드 자체를 통할 수도 있다. UBIQUITOUS LANGUAGE 도메인 전문가와 개발자가 각자 자기의 언어를 사용하면 안된다. 이는 정보 흐름의 병목으로 이어지며 그들이 번역하는 바도 정확하지 않다.유비쿼터스 언어를 사용하지 않을때 발생하는 문제는 다음과 같다. - 각자의 언어로 얘기를 하기 때문에 토론이 되지 않는다. - 용어와 코드의 정보가 단절된다.- 번역은 의사소통을 무디게 하고 지식탐구를 빈약하게 만든다. 브레인스토밍과 실험 중 언어에 공..