본문 바로가기

55

[도메인 주도 개발하기] 2장 아키텍처 개요 2장 아키텍처 개요 생성일: 2024년 1월 29일 오후 10:32 아키텍처 웹브라우저에서 요청(HTTP)→표현영역에서 요청을 가공 후 응용영역에 전달 → 응용영역이 처리 결과를 표현영역에 전달 →표현영역이 응답결과를 가공 후 사용자(웹브라우저)에게 보여줌 표현영역은 HTTP요청을 변환 → 응용영역에 전달 , 응용영역의 응답을 HTTP응답으로 변환→웹 브라우저에 전송 ex) HTTP 파라미터를 객체타입으로 변환 , 응용영역의 결과를 JSON형식으로 변환 응용영역은 제공해야할 기능을 직접 구현 X, 도메인 모델에 로직 수행을 위임 ex) 주문 취소 로직을 직접 구현 X, Order 객체에 취소 처리를 위임. 도메인 영역은 도메인 모델 구현과 핵심 로직 구현 ex) ‘배송지 변경’, ‘결제완료’, ‘주문 총.. 2024. 1. 30.
[Clean Code] 3장 함수 [Clean Code] 3장 함수 생성일: 2024년 1월 17일 오후 4:42 추상화 수준 작게 만들어라! 💡 작은 함수가 좋다. (2~4줄) if, else, while 문 등에 들어가는 블록은 함수를 호출하는 한 줄이 좋다. **내려가기 규칙 ***추상화 수준이 한 단계 낮은 함수를 호출하기 **** 한 가지만 해라 💡 함수는 한 가지를 해야 한다. 한 가지를 잘 해야 한다. **한 가지만 하는 함수** 1. 추상화 수준이 하나인 단계만 수행한다. 2. 의미 있는 이름으로 다른 함수를 추출할 수 있다. 한 가지만 하려면 ? 함수 당 추상화 수준은 하나로! 💡 함수 내 모든 문장의 추상화 수준을 동일하게 한다. 한 함수 내에 추상화 수준을 섞으면 읽을 때 헷갈린다. 근본 개념인지 아니면 세부사항인지 .. 2024. 1. 30.
[Clean Code] 1장 깨끗한 코드 들어가는 말 요구사항을 명세하는 수단이므로 코드는 사라질 수 없다. 코드는 요구사항의 정밀하게 명시한 표현 나쁜코드 & 나쁜코드로 치르는 대가 잘 나가던 앱을 만든 회사가 망한 원인 은 나쁜코드 때문이다. 버전이 올라가도 버그가 남아있으며 프로그램이 죽는 횟수도 늘었다. 제대로 짤 시간이 없어서 나쁜코드를 보며 나중에 손보겠다고 생각하지만 다시 돌아와 정리하는 일은 오지 않는다. *르블랑의 법칙 : 나중은 결코 오지 않는다. 나쁜 코드는 프로젝트 초반에는 빠른 것처럼 보이지만 수정에 많은 노력이 필요하며 엉뚱한 곳에서 문제가 생긴다. 결국 팀 생산성이 떨어져 인력을 추가하여 복구를 시도하지만 새 인력은 시스템 설계에 대한 이해가 떨어진다. 설계 의도에 맞는 변경과 설계 의도에 반하는 변경을 구분하지 못하.. 2024. 1. 30.