사전작업

  1. Homebrew 설치 : http://brew.sh/
  2. JDK 설치. 가능하면 현재 최신 버전으로 설치한다.
    • Homebrew를 이용한 설치 : OS X에 Homebrew로 JDK설치
    • Web에서 직접 다운로드 : http://www.oracle.com/technetwork/java/javase/downloads/index.html
  3. JAVA_HOME 환경변수 설정
    • ~/.bash_profile 파일에 아래와 같이 추가해서 환경변수 설정을 한다.
$ vi ~/.bash_profile
# vi
export JAVA_HOME = /System/Library/Frameworks/JavaVM.framework/Versions/CurrentJDK/Home
# :wq (저장)

환경변수 적용을 위해서 사용자계정 로그오프 후 재접속 해야한다.

IntelliJ-IDEA 설치

  • web에서 직접 다운로드 (추천) : https://www.jetbrains.com/idea/download/
  • Homebrew를 이용한 설치 : OS X에 Homebrew로 IntelliJ 설치
    • Homebrew로 설치 후 업그레이드 시 잔재가 남음

IntelliJ 튜닝

IntelliJ의 설치파일이 존재하는 경로로 이동하면 idea.vmoption 파일이 존재

  • /Applications/IntelliJ IDEA 14.app/Contents/bin/idea.vmoption

원본

Xms128m
Xmx750m
XX:MaxPermSize=350m
XX:ReservedCodeCacheSize=225m
XX:+UseCompressedOops

튜닝

Xms1024m
Xmx1024m
XX:MaxPermSize=350m
XX:ReservedCodeCacheSize=225m
XX:+UseCompressedOops
XX:+UseG1GC
  • XX:ReservedCodeCacheSize=225m : JIT 컴파일러 캐시 사이즈
  • XX:+UseCompressedOops : 32bit 형으로 데이터 압축
  • XX:+UseG1GC : G1 GC 활성화화

최소한의 튜닝을 기조로 설정함

IntelliJ 레티나 폰트 가독성 향상

  • 일부 폰트가 레티나 디스플레이를 표현 못할 경우 아래 파일의 일부 내용 수정 요망
  • /Applications/IntelliJ IDEA 14.app/Contents/Info.plist

원본

...
<key>JVMVersion</key>
<string>1.8*</string>
...

튜닝

...
<key>JVMVersion</key>
<string>1.8+</string>
...

IntelliJ 환경설정

Editor > General > Appearance

  • Show line nubmers 활성화
  • Show whitespaces 활성화

Editor > General > Appearance

Font

  • Save As... 클릭 후 새로운 Scheme를 저장
  • Primary 폰트 설정
  • Secondary 폰트 설정 (Primary 폰트에 없는 문자-예를들면 한글-에 대한 대처폰트)

Font

Auto Import

  • Optimize imports on the fly 활성화
  • Add unambiguous imports on the fly 활성화

Auto Import

File Encoding

  • Transparent native-to-ascii conversion 활성화

File Encoding

Time Tracking

  • Enable Time Tracking 활성화

Time Tracking

Mark modified tabs

  • Mark modified tabs with asterisk 활성화
  • 수정된 파일에 * 표시

Mark modified tabs

본 포스트는 도메인 주도 설계 라는 책을 참조하였습니다. 가능하면 본 책을 직접 보시고 DDD를 이해하는 것을 추천드립니다. http://www.aladin.co.kr/shop/wproduct.aspx?ItemId=12174216

LAYERED ARCHITECTURE (계층형 아키텍처)

도메인과 관련없는 코드들이 각 계층에 산재하게 되면?

  • 응집력 있고, 모델 주도적인 객체를 구현하는 것이 비현실적인 이야기가 돼버린다.
  • 자동화 테스트가 어렵다.
  • 도메인에 관련된 코드를 확인하고 추론하기가 굉장히 힘들어진다.

이를 해결하기 위해서는

  • 관심사의 분리 (separation of concern)
  • 즉, 계층 분리

계층화의 핵심원칙

  • 한 계층의 모든 요소는 오직 같은 계층에 존재하는 다른 요소나 계층상 아래 에 위치한 요소에만 의존한다.
  • 위로 거슬러 올라가는 의사소통은 반드시 간접적인 매커니즘을 거쳐야 한다.

계층화의 가치 (장점)

  • 응집력 강화
  • 이해도 향상

대표적인 4계층 아키텍처

사용자 인터페이스 (표현 계층)
응용 계층
  • 소프트웨어가 수행할 작업을 정의하고 표현력 있는 도메인 객체가 문제를 해결하게 한다. - 일종의 위임과 상호작용
  • 실제 업무를 처리하는 것은 아래 도메인 계층에서 한다. 또한 상태를 가질 수도 없다.
  • 트랜젝션 관리가 이 계층에서 이루어진다.
도메인 계층 (모델 계층)
  • 실제 업무 처리. 업무용 소프트웨어의 핵심 계층
인프라스트럭쳐 계층
  • 메세지 전송
  • 도메인 영속화 (예를 들면 DB 저장)

계층화

MODEL-DRIVEN DESIGN을 가능하게 하는 것은 결정적으로 도메인 계층 분리

  • 복잡한 프로그램을 여러 개의 계층으로 나눠라.
  • 응집력 있고 오직 아래에 위치한 계층에만 의존하는 각 계층에서 설계를 발전시켜라.
  • 표준 아키텍처 패턴에 따라 상위 계층과 결합을 느슨하게 유지하라.
  • 도메인 모델과 관련된 코드는 모두 한 계층에 모으로 사용자 인터페이스 코드나, 어플리케이션 코드, 인프라스트럭처 코드와 격리하라.
  • 도메인 객체(표현이나 저장, 애플리케이션 작업을 관리하는 등의 책임에서 자유로운)는 도메인 모델을 표현하는 것에만 집중할 수 있다.

계층화 결론

모델은 진화를 거듭해 본질적인 업무 지식을 포착해서 해당 업무 지식이 효과를 발휘할 수 있을 만큼 풍부하고 명확해질 것이다.

계층 간 관계 설정

  • 계층 간 분리의이점을 잃지 않으면서 각 계층을 서로 연결하는 것이 중요 : 패턴 존재의 이유
  • 상위 계층에서 하위 계층으로 공개 인터페이스를 통한 느슨한 연결
  • 만약, 하위 계층에서 상위 계층으로 소통해야할 경우 Callback이나 Observer Parttern 등의 아키텍처 패턴을 활용한다.
  • MVC 패턴 : 도메인, UI, 응용계층을 연결하는 패턴
  • 인프라스트럭처 계층을 Service 추상화를 통해서 느슨하게 연결하는 것이 좋음
  • 하지만, 직접적으로 인프라스트럭처를 바로 호출할 수도 있음 (Service를 통하지 않고)

아키텍처 프레임워크

  • 일반적으로는 인프라스트럭처 계층을 이용할 시에는 Service를 통하는 것이 좋다
  • 하지만 인프라 스트럭쳐로 직접 접근이 필요할 때가 있으며, 이런한 문제를 해결하기 위해서 아키텍처 프레임워크가 필요하다.
  • 필요한 기능 만큼만으로 프레임워크를 구성하고, 도메인 모델에 집중할 수 있는 아키텍처를 만들자???? - 프레임워크가 아니라 기능에 의존하자??

잘 이해가 안됨 아키텍처 프레임워크의 필요성을 강조하나 명확하게 이해가 되지 않음

도메인 계층은 모델이 살아가는 곳

DDD에서 중요한 것은 도메인 계층 에 모델과 설계 요소에 관련 모든 것을 명시하고 격리하는 것이다.

SMART UI(지능형 UI) “안티 패턴”

SMART UI vs DDD

두 방법론은 양립할 수 밖에 없다.

  • 간단한 요구사항에는 그에 맞는 구조가 필요하다. - SMART UI와 같은
  • DDD는 복잡한 수준의 요구사항에 어울리다.

SMART UI 패턴이란?

UI와 콤포넌트가 강결합 상태로 구현 하는 것 예를들면 jsp 내부에서 DB 로직까지 제어하는 거와 같은 절차적프로그래밍에 가까운 그것을 의미한다.

빠르고 상대적으로 이해하기 쉬운 장점이 있으나, 단점은 추상화가 이루어지지 않기 때문에 재사용성이 낮고 리팩터링이 힘들고, 복잡성 대응에 힘들다. 결국은 유지보수가 점점 힘들어져 빠르게 레거시 시스템 이 되버린다.

SMART UI 교훈을 통해서 왜 격리(LAYRED ARCHITECTURE)가 필요한지를 역설적으로 알아본다.

트랜젝션 스크립트 패턴이란?

  • SMART UI와 DDD 중간 쯤 위치
  • UI와 로직은 분리하지만 객체에 모델은 제공하지 않는다.
  • 아키텍처에서 응집력 있는 도메인 설계가 시스템의 다른 부분과 느슨하게 결할될 수 있게 도메인 관련 코드를 격리한다면 아마 그러한 아키텍처는 도메인 주도 설계를 지원할 수 있을 것이다.

복잡한 어플리케이션을 개발하고 있고, MODEL-DRIVEN DESIGN을 하기로 했다면 고통을 감내하고 필요한 전문가를 확보하며 SMART UI를 피해야한다.

다른 종류의 격리

다른 종류의 격리는 다른 챕터에서 다루므로 지금은 그런 게 있다는 정도만 알아두자

중요한 것은 도메인을 격리의 장점은 부수적인 것을 배제하고 도메인 설계에만 집중 할 수 있다는 것이다.

  • macOs High Sierra 업데이트 시 발생
  • macOs High Sierra 업데이트 시 발생
  • macOS Sierra 업데이트 시 발생
  • OS X El Capitan 업데이트 시 발생

그냥 연례행사 인 듯…

언제나 처럼 먼저 업데이트하면 골치아픈 일이 많이 생기네요 ㅠ

그러던 중에 Xcode Command Line Tools 의존성 이슈가 발생하는 경우가 생겼다. git을 실행시키는데 아래와 같은 오류와 함께 실행이 되지 않는 케이스이다.

$ git --version
xcrun: error: invalid active developer path (/Library/Developer/CommandLineTools), missing xcrun at: /Library/Developer/CommandLineTools/usr/bin/xcrun

XCode를 재설치하면 해결되나 나와 같은 전체설치가 필요하지 않는 경우에는 Xcode Command Line Tools만 설치할 수 있다.

$ xcode-select --install

설치 후 2343 최신버전으로 확인된다.

$ xcode-select -v
xcode-select version 2343.

출처 : http://stackoverflow.com/questions/32893412/command-line-tools-not-working-os-x-el-capitan

본 포스트는 도메인 주도 설계 라는 책을 참조하였습니다. 가능하면 본 책을 직접 보시고 DDD를 이해하는 것을 추천드립니다. http://www.aladin.co.kr/shop/wproduct.aspx?ItemId=12174216

네비게이션 맵

MODEL-DRIVEN DESIGN의 언어로 구성된 내비게이션 맵

출처 : http://www.infoq.com/minibooks/domain-driven-design-quickly

본 포스트는 도메인 주도 설계 라는 책을 참조하였습니다. 가능하면 본 책을 직접 보시고 DDD를 이해하는 것을 추천드립니다. http://www.aladin.co.kr/shop/wproduct.aspx?ItemId=12174216

구현에 도움이 되는 모델링

  • 간결
  • 이해가 쉽고
  • 유지보수에 용의
  • 초기 분석에 도움
  • 설계의 기반

MODEL-DRIVEN DESIGN (모델 주도 설계)

코드와 모델이 긴민하게 연결되면 코드에 의미가 부여되고 모델과 코드가 서로 대응하게 된다.

  • 분석모델(analysi model) : 오로지 도메인 분석만을 위한 모델.
  • 구현모과 철저하게 분리되어 있기 때문에 유지하는 비용이 너무 비싸다. (구현 시에는 다른 모델링이 요구됨)
  • 순수하게 이론적인 내용을 위주로 다루기 때문에 코딩이 시작되면 폐기.
  • 중요한 발견은 언제나 설계/구현을 위해 노력하는 가운데 나타난다. (분석 시에는 발견하기 힘들다)

설계가 도메인 모델에 대응해야하며, 설계와 모델 사이에는 단순한 대응으로 이해가 쉬워야한다.

  • 수월한 유지보수가 가능
  • 소프트웨어의 정확도 향상
  • 분석과 설계의 긴밀한 연합으로 인한 도메인전문가와 개발자 간 통찰력 유대

MODEL-DRIVEN DESIGN은 분석모델과 설계를 나누지 않는다

  • 분석과 설계라는 두마리 토끼를 잡아야한다.
  • 이는 절대로 쉽지 않은 일이다.

소프트웨어 시스템의 일부를 설계할 때는 도메인 모델을 있는 그대로 반영해서 설계와 모델의 대응을 분명하게하라. 또한 모델을 재검토해서 더욱 자연스럽게 소프트웨어로 구현될 수 있게 수정하라. 도메인에 과한 더욱 심층적인 통찰력을 반영하려 할 때도 마찬가지이다. 이렇듯 견고한 UBIQUITOUS LANGUAGE를 지원하는 것과 더불어 분석과 설계의 두 가지 측면을 충분히 만족하는 단 하나의 모델을 만들어내야 한다.

모델로부터 설계와 기본적인 책임할당에 사용한 용어를 도출하라. 코드를 작성할 때 그러한 용어를 사용하면 코드가 모델을 표현한 것이 되고, 코드의 변경이 곧 모델의 변경으로 이어질 수 있다. 그 효과는 프로젝트의 나머지 활동에도 퍼져나가야 한다.

구현을 모델과 그대로 묶으려면 보통 객체지향 프로그래밍과 같은 모델링 패러다임을 지원하는 소프트웨어 개발 도구와 언어가 필요하다

모델링 패러다임 도구 지원

// TODO 그림 3-1 삽입

이 부분은 잘 모르겠음. - 다시 한 번 읽어보자.

내부 드러내기: 왜 모델이 사용자에게 중요한가

설계가 사용자(UI, UX)와 도메인 전문가의 기본적인 관심사를 반영하는 모델에 기반을 두면 설계의 골격이 다른 설계 접근법에 비해 더 큰 범위에 걸쳐 사용자에게 드러날 수 있다. 모델이 드러나면 사용자가 소프트웨의 잠재력을 좀 더 많이 접하게 되어 일관성 있고 예상 가능한 행위가 나타날 것이다.

HANDS-ON MODELER (실천적 모델러)

분석, 모델링, 설계, 프로그래밍에 대한 책임을 지나치게 구분하는 것(폭포수 모델)은 MODEL-DRIVEN DESIGN 과 상충한다.

기존 방식 모델링의 2가지 단점

  1. 모델의 의도 중 일부가 이관되면서 사라짐. 세부사항은 일반적인 토의 내용에서는 발견되지 않음.
  2. 모델의 구현과 기술과의 상호 작용에 대한 피드백이 간접적일 수 밖에 없다. 모델링과 구현을 격리 시키므로

코드를 작성하는 사람이 모델에 책임을 느끼지 못하거나 애플리케이션을 대상으로 모델이 동작하게 만드는 법을 모른다면 그 모델은 소프트웨어와 무관해진다. 코드의 변경이 곧 모델의 변경이라는 점을 개발자가 인식하지 못하면 리팩터링은 모델을 강화하기보다는 약화시킬 것이다. 한편으로 모델러가 구현 프로세스와 분리돼 있을 경우, 구현상의 제약조건을 감안하는 능력을 결코 갖추지 못하거나 금방 잃어버릴 것이다. 모델이 효과적인 구현을 뒷받침하고 핵심 도메인 지식을 추상화한다는 MODEL-DRIVEN DESIGN의 기본적인 제약조건은 절반쯤 사라지고, 결과로 나타나는 모델은 실용적이지 못할 것이다. 결국 MODEL-DRIVEN DESIGN을 코드로 만드는 과정의 미묘한 사항들은 협업을 통해 알 수 있는데, 설계자가 구현을 하지 못해 개발자와 업무의 단절이 생기면 숙련된 설계자의 지식과 솜씨는 결코 다른 개발자에게 전해지지 못할 것이다.

모델에 기여하는 모든 기술자는 프로젝트 내에서 수행하는 일차적 역할과는 상관없이 코드를 접하는 데 어느 정도 시간을 투자해야만 한다. 코드를 변경하는 책임이 있는 모든 이들은 코드를 통해 모델을 표현하는 법을 반드시 배워야 한다. 모든 개발자는 모델에 관한 일정 수준의 토의에 깊이 관연해야 하고 도메인 전문가와도 접촉해야 한다. 다른 방식으로 모델에 기여하는 사람들은 의식적으로 코드를 접하는 사람들과 UBIQUITOUS LANGUAGE를 토대로 모델의 아이디어를 나누는 데 적극 참여해야 한다.