profile
기초를 탄탄하게

[테스트주도개발] 다중 통화를 지원하는 MONEY 객체

작은 테스트를 하나 추가한다.모든 테스트를 실행해서 테스트가 실패하는 것을 확인한다.조금 수정한다.모든 테스트를 실행해서 테스트가 성공하는 것을 확인한다.중복을 제거하기 위해 리팩토링을 한다. 우리가 알고 있는 작업해야 할 테스트 목록을 만든다.오퍼레이션이 외부에서 어

2022년 3월 21일
·
0개의 댓글

[클린코드] 클래스

정적 공개 상수정적 비공개 변수비공개 인스턴스 변수공개 변수 (거의없음)공개 함수비공개 함수캡슐화를 풀어주는 결정으 ㄴ언제나 최후의 수단이다.클래스는 작아야 한다.클래스가 맡은 책임을 센다.클래스 이름은 해당 클래스 책임을 기술해야 한다. (작명은 클래스 크기를 줄이는

2022년 2월 13일
·
0개의 댓글

[클린코드] 오류처리

오류코드를 사용하지 않으면 호출자 코드가 복잡해진다.예외를 사용하면 호출자 코드가 깔끔해진다.에러부분과 본문이 분리되어 관리가 된다,try블록은 트랜잭션과 비슷하다. 예외 유형을 좁혀서 관리한다. Exception -> FileNotFooundException확인된 예

2022년 2월 6일
·
0개의 댓글

[클린코드] 형식맞추기

의사소통의 일환이다구현한 코드의 가독성은 앞으로 바뀔 코드의 품질에 지대한 영향을 미친다.200줄 미만으로 작성하라큰파일 보다는 작은 파일이 이해하기 쉽다.이름은 간단하면서도 설명이 가능하게 짓는다.이름만 보고도 올바른 모듈을 살펴보고 있는지 아닌지를 판단할 정도로 신

2022년 1월 23일
·
0개의 댓글

[클린코드] 함수

의도를 분명히 표현하는 함수를 어떻게 구현할 수 있을까? 함수에 어떤속성을 부여해야 처음 읽는 사람이 프로그램 내부를 직관적으로 파악할 수 있을까?함수가 이야기를 표현한다.if/esle 문, while문 등에 들어가는 블록은 한줄이여야 한다. 들여쓰기 수준은 1단이나

2022년 1월 16일
·
0개의 댓글

[클린코드] 의미 있는 이름

존재 이유는?수행 기능은?사용 방법은? 여러 계정을 그룹으로 묶을때 실제 List가 아니라면, accountList라 명명하지 않는다.Info, Data, 연속된 숫자 불용어 사용을 지양한다. 변수에 variable, 표에 table 과같은 중복성은 피한다.프로그래밍은

2022년 1월 9일
·
0개의 댓글

[오브젝트] 합성과 유연한 설계

전체를 표현하는 객체가 부분을 표현하는 객체를 포함해서 부분 객체의 코드를 재사용한다.두 객체 사이의 의존성은 런타임에 해결된다. has-a 관계라고 부른다.상속과 달리 내부에 포함되는 객체의 구현이 아닌 퍼블릭 인터페이스에 의존한다. 객체사이의 동적관계이다.구현관점에

2021년 12월 26일
·
0개의 댓글

[오브젝트] 상속과 코드 재사용

신뢰할 수 있고 수정하기 쉬운 소프트웨어를 만드는 효과적인 방법 중 하나는 중복을 제거하는 것이다.DRY원칙모든 지식은 시스템 내에서 단일하고, 애매하지 않고, 정말로 믿을 만한 표현 양식을 가져야 한다.자식 클래스의 메서드 안에서 super 참조를 이용해 부모 클래스

2021년 12월 21일
·
0개의 댓글

[오브젝트] 유연한 설계

소프트웨어 개체(클래스, 모듈, 함수 등등)는 확장에 대해 열려 있어야 하고, 수정에 대해서는 닫혀 있어야 한다.확장에 대해 열려 있다. 애플리케이션의 요구사항이 변경될 때 이 변경에 맞게 새로운 '동작'을 추가해서 애플리케이션의 기능을 확장할 수 있다.수정에 대해 닫

2021년 12월 20일
·
0개의 댓글

[오브젝트] 의존성 관리

객체지향 설계란 의존성을 관리하는 것이고 객체가 변화를 받아들일 수 있게 의종성을 정리하는 기술이다.어떤 객체가 협력하기 위해 다른 객체를 필요로 할 때 두 객체 사이에 의존성이 존재하게 된다. 실행시점: 의존하는 객체가 정상적으로 동작하기 위해서는 실행 시에 의존 대

2021년 12월 19일
·
0개의 댓글
post-thumbnail

[DDD] 전략의 종합

프로젝트에 대한 전략적 설계를 다 룰 때는 현 상황을 명확하게 평가하라.Context Map을 그려라프로젝트상의 언어를 쓰는 데 힘써라.무엇이 중요한지 이해하라.MODEL_DRIVEN DESIGN에 유리한가?팀 내 개발자가 필요한 기술 역량을 갖췄는가?개발자들이 도메인

2021년 12월 9일
·
0개의 댓글

[DDD]대규모 구조 #2

더 넓은 범위의 규칙으로 제약되기 전까지 모델의 특정 부분을 사용 자의 손에 맡겨야 할 때 생기는 문제를 해결한다.구성가능한 행위를 갖춘 소프트웨어의 요구사항을 다루는데, 여기서 구성 가능하다는 것은 여러 ENTITY 간의 역할과 관계를 초기화 시점이나 실행 시점에서도

2021년 12월 8일
·
0개의 댓글
post-thumbnail

[DDD] 대규모 구조

큰 시스템에 해당 시스템의 요소를 전체 설계에 걸친 패턴에서의 역할 측면에서 해석하게 할 수 있는 지배적인 원칙이 없다면 개발자들은 나무만 보고 숲을 보지 못한다.전체의 세부사항을 깊이 파고들지 않고도 전체의 각 부분이 담당하는 역할을 이해할 수 있어야 한다.대규모 구

2021년 12월 7일
·
0개의 댓글

[DDD]디스틸레이션 #2

프로젝트 초기에는 모델이 존재조차 하지 않지만 모델의 개발에 집중해야 할 필요성은 거기에 있다.개발이 후반부에 이르면 모델을 심층적으로 연구하지 않아도 되는 시스템의 가치를 설명할 필요가 생긴다. 도메인 모델의 핵심적인 측면이 다수의 BOUNDED CONTEXT에 걸쳐

2021년 11월 29일
·
0개의 댓글

[DDD] GENERIC SUBDOMAIN

모델의 일부는 전문 지식을 포착하거나 전달하지 않고 복잡성을 더하곤 한다.부수적인 요소는 CORE DOMAIN을 식별하고 이해하는 일을 어렵게 한다.모델은 일반 원칙이나 세부사항 탓에 정체된다.CORE가 모든 상호 관련된 요소와 섞여 있으면 어렵다.현재 진행 중인 프로

2021년 11월 25일
·
0개의 댓글
post-thumbnail

[DDD] 디스틸레이션

혼합된 요소를 분리해서 본질을 좀더 값지고 유용한 형태로 뽑아내는 과정이다. 팀원들이 시스템의 전체 설계와 해당 설계가 어떻게 함께 조화될지 파악하게끔 돕는다. UBIQUITOUS LANGUAGE의 일부가 될 수 있게 관리 가능한 크기의 핵심 모델을 식별해서 의사소통을

2021년 11월 24일
·
0개의 댓글

[DDD] SEPARATE WAY / OPEN HOST SERVICE / PUBLISHED LANGUAGE

통합에는 언제나 비용이 많이든다.때로는 통합의 혜택이 적은 경우도 있다.BOUNDED CONTEXT가 다른 것과 아무런 관계도 맺지 않도록 선언해서 개발자들이 이 작은 범위 내에서 단순하고 특화된 해결책을 찾을 수 있게 하라.일부 대안은 사전에 차단된다.완벽하게 격리된

2021년 11월 11일
·
0개의 댓글
post-thumbnail

[DDD] ANTICORRUPTION LAYER

개념적인 객체와 행위를 하나의 모델과 프로토콜에서 다른 모델과 프로토콜로 변환하기 위한 메커니즘이다.Bounded Context를 있는 수단이다.다른 시스템과 상호작용하기 위한 거대한 인터페이스를 보유한 새로운 시스템을 구축할 경우 두 모델을 연계하는 데 따르는 어려움

2021년 11월 10일
·
0개의 댓글

[DDD] CONFORMIST

두 개발 팀이 상류/하류 관계를 맺고 있고 상류 팀이 하류 팀의 필요성을 충족시킬 충분한 동기를 느낄수 없다면 하류팀은 속수무책으로 무력해질 수 밖에 없다.상류 개발자들이 약속을 할 수는 있어도 그 약속을 이행할 가능성은 희박하다.상류 팀의 선한 의도를 신뢰한 하류 팀

2021년 11월 8일
·
0개의 댓글

[DDD]CUSTOMER/SUPPLIER DEVELOPMENT TEAM

변경에 대한 거부권이 하류팀에 있거나 변경 요청절차가 지나치게 복잡하다면 상류 팀이 자유롭게 개발을 진행하는 데 하류팀에 속박당할 여지가 있다. 상류 팀은 하류 시스템이 잘못될 것을 염려해서 개발 자체를 억제할지도 모른다.동시에 하류 팀은 상류 팀의 우선순위에 따라

2021년 11월 7일
·
1개의 댓글