절대적 발전

도메인 헥사곤으로 비즈니스 모델링엔티티를 활용한 문제영역 모델링도메인 엔티티의 순수성문제영역 모델링의 주요 초점은 최대한 실제 시나리오를 코드로 변환하는 것, 비즈니스 요구사항을 이해하고 코드로 변환하는데 실패하면 결과적으로 비용의 손실이 발생할 수 밖에 없다문제영역 모델링의 핵심은 엔티티를 만드는 것이다. 엔티티가 비즈니스 요구사항과 밀접한 관계를 가져야 하기 때문에, 비즈니스 관련 코드와 기술 관련 코드가 혼동되는 것을 방지 해야한다.(기술적: 소프트웨어 맥락에서만 존재하고 의미가 있는 것)헥사고날 아키텍처는 전통적인 비즈니스 문제를 해결하려는 프로젝트에 초점이 맞춰져 있기 때문에, 새로운 개발 프레임워크와 같은 순수하게 기술적인 프로젝트에는 최선의 접근 방법이 아닐 수도 있다.도메인 엔티티는 비즈니..

프레임워크 헥사곤소프트웨어와 통신할 수 있는 기술을 결정한다. 통신은 두 가지 형태로 발생할 수 있다.드라이빙 방식(Driving): 입력 어댑터(Input Adapter)를 사용한다.드리븐 방식(Driven): 출력 어댑터(Output Adapter)를 사용한다.드라이빙 오퍼레이션과 입력 어댑터드라이빙 오퍼레이션은 소프트웨어에 동작을 요청하는 것이다.웹 애플리케이션에서 사용자가 버튼 눌러 폼을 제출하는 경우외부 시스템에서 REST API로 애플리케이션에 데이터를 요청하는 경우외부 시스템에서 MQ로 메세지를 보내는 경우이러한 API는 외부 엔티티가 시스템과 상호작용하고, 외부 엔티티의 요청을 도메인 애플리케이션으로 변환하는 방법을 정의한다.드라이빙이라는 단어는 외부 엔티티들이 시스템의 동작을 유도하기 때..

애플리케이션 헥사곤애플리케이션 특화 작업을 추상적으로 처리하는 곳, 기술 관심사를 직접 다루지 않기 때문에 추상적인 것을 이야기한다. 도메인 비즈니스 규칙에 기반한 소프트웨어 사용자의 의도와 기능을 표현한다.유스케이스도메인 제약사항을 지원하기 위해 시스템의 동작을 소프트웨어 영역 내에 존재하는 애플리케이션 특화 오퍼레이션을 통해 나타낸다.엔티티 및 다른 유스케이스와 직접 상호작용하고 그것을 유연한 컴포넌트로 만들 수 있다.자바에서는 인터페이스로 정의된 추상화로 나타낸다.public interface RouterViewUseCase { List getRouters(Predicate filter);}입력 포트유스케이스 인터페이스를 구현하는 것이 입력 포트의 역할 이다. 애플리케이션 수준에서 유스케이스에..

도메인 헥사곤실 세계 문제를 이해하고 모델링하는 활동스타트업 같은 개발자나 도메인 전문가 모두 시스템의 목적에 대한 명확한 비전을 갖고 있지 않거나,문제 영역이 존재하고 도메인 전문가들이 분명하게 알고 있는 상황에서 문제 영역을 엔티티, 값 객체로의 변환 방법을 파악하지 못하면 잘못된 가정을 기반으로 구축되게 될 것이다.이러한 점은 소프트웨어가 간단하게 시작해서, 기반 코드가 커짐에 따라 기술 부채가 누적되고 유지 보수가 더 어려워지는 이유 중 하나로 여겨진다.엔티티식별자 (Identifier): 엔티티는 고유한 식별자를 가지고 있으며, 이 식별자를 통해 다른 엔티티와 구분된다. 동일한 엔티티는 시간이 지나도 동일한 식별자를 유지한다.변경 가능성 (Mutability): 엔티티는 시간이 지남에 따라 상태..

포트와 어댑터 아키텍쳐라고도 불림 메인 아이디어비즈니스 코드를 기술 코드로부터 분리하는 것비즈니스 코드에 피해를 주지 않고 기술 코드 변경이 가능해야 한다핵심 도메인 로직을 외부 인터페이스(입출력, DB, 사용자 인터페이스 등)으로 부터 분리함으로 달성도메인 헥사곤소프트웨어가 해결하기를 원하는 핵심 문제를 설명하는 요소의 결합, 이러한 요소들은 기술에 구애 받지 않는 형태로 표현되어야 함구성 요소엔티티 - 식별자를 할당할 수 있는 것값 객체 - 엔티티들을 합성하기 위한 불변 객체애플리케이션 헥사곤도메인 헥사곤에서 나오는 비즈니스 규칙을 사용, 처리, 조정비즈니스 측면과 기술 측면 사이에서 양쪽과 상호작용하는 중개자 역할프레임워크 헥사곤애플리케이션 기능의 노출 방법을 결정, 예를 들면 REST, gRPC ..

사내에서 Querydsl에 대해 Tech Talk 진행할 기회가 생겨 준비한 내용을 기록합니다 Querydsl 타입에 안전한 방식으로 HQL 쿼리를 실행하기 위한 목적으로 만들어짐 타입에 안전하도록 도메인 모델을 변경하면 소프트웨어 개발에서 큰 이득을 얻게 됨 도메인 변경이 직접적으로 쿼리에 반영됨 쿼리 작성 과정에서 코드 자동완성 기능을 사용함으로써 쿼리를 더 빠르고 안전하게 만들 수 있게 됨 JPA, JDO, JDBC, Lucene, Hibernate Search, MongoDB, Collections 그리고 RDFBean을 지원 사용하기 도메인 타입 작성(ex: Customer) Querydsl에 의해 자동으로 QCustomer라는 쿼리타입 생성 (JPA의 경우) JPAQuery 인스턴스로 쿼리 작..

객체는 인터페이스를 사용해 참조하라 이전에 매개변수 타입으로 클래스가 아닌 인터페이스를 사용하라고 하였다, 이를 확장하면 객체는 클래스가 아닌 인터페이스로 참조하라고 할 수 있다 즉 적합한 인터페이스만 있으면 매개변수뿐 아니라 반환값, 변수, 필드를 전부 인터페이스 타입으로 선언하라. // 좋은 예, 인터페이스를 타입으로 사용 Set itemSet = new LinkedHashSet(); // 나쁜 예, 클래스를 타입으로 사용 LinkedHashSet itemSet = new LinkedHashSet(); 인터페이스를 타입으로 사용하는 습관을 길러두면 프로그램이 훨씬 유연해진다, 나중에 구현 클래스를 교체하고자 한다면 그저 새 클래스의 생성자(혹은 다른 정적 팩터리)를 호출해주기만 하면 된다. Set i..

메서드 시그니처를 신중히 설계하라 개별 아이템으로 두기 애매한 API 설계 요령들을 모아 놓았다. 배우기 쉽고, 쓰기 쉽고, 오류 가능성이 적은 API를 만들기 위함이다. 메서드 이름을 신중히 짓자. 항상 표준 명명 규칙(아이템68)을 따라야 한다. 이해할수 있고, 같은 패키지에 속한 다른 이름들과 일관되게 짓는 게 최우선 목표다. 그다음은 개발자 커뮤니티에서 널리 받아들여지는 이름을 사용하는 것이다. 긴 이름은 피하자. 애매하면 자바 라이브러리의 API 가이드를 참조하라. 자바 라이브러리가 워낙 방대하다 보니 일관되지 않은 이름도 제법 많지만 대부분은 납득할 수준이다. 편의 메서드를 너무 많이 만들지 말자 모든 메서드는 각각 자신의 소임을 다해야 한다. 메서드가 너무많으면 익히고 사용하고 문서화하고 테..

성능을 생각한다면 String 대신 StringBuilder 문자열 연결 연산자(+)는 편리하지만, 성능 위주의 환경에서는 성능 저하를 감내하기 어려울 것이다. 문자열 연결 연산자로 문자열 n개를 잇는 시간은 n^2에 비례한다. 문자열은 불변이라서 두 문자열을 연결할 경우 양쪽의 내용을 모두 복사해야 하므로 성능 저하는 피할 수 없다. public String statement() { // 문자열 연결을 잘못 사용한 예 - 느리다! String result = ""; for (int i = 0; i < numItems(); i++) { result += lineForItem(i); // 문자열 연결 } return result; } 성능을 포기하고 싶지 않다면 StringBuilder를 사용하자 publ..

박싱된 기본 타입보다는 기본 타입을 사용하라 자바의 데이터 타입 기본타입 - int, double, boolean ... 참조타입 - String, List ... 박싱된 기본 타입 - Integer, Double, Boolean ... 오토박싱과 오토언박싱 덕분에 두 타입을 크게 구분하지 않고 사용할 수는 있지만 차이는 있다. 어떤 타입을 사용하는지는 상당히 중요하다. 기본타입과 박싱된 기본 타입과의 차이 기본 타입은 값만 가지고 있으나, 박싱된 기본 타입은 값에 더해 식별성이란 속성을 갖는다. 즉 두 인스턴스의 값이 같아도 다르다고 식별 될 수 있다. 기본 타입의 값은 언제나 유효하나, 박싱된 기본 타입의 값은 null(유효하지 않은 값)을 가질 수 있다. 기본 타입이 시간과 메모리 사용면에서 유리하..