왜 지름길은 깨진 창문과 같을까?깨진 창문 이론어떤 것이 멈춘 것처럼 보이고, 망가져 보이고, 관리되지 않는다고 여겨지면 인간의 뇌는 이를 더 멈추고, 망가뜨리고, 관리하지 안 해도 된다고 생각하게 된다. (Philp Zimbardo)망가진 자동차와 안 망가진 자동차를 주차해두고 실험해 본 결과 사람들은 망가져 있는 자동차를 더 망가트리거나 부품들을 도난했다. 반대로 안 망가진 자동차를 그대로 유지가 되는 결과가 있었다. 하지만, 안 망가진 자동차의 창문을 깨트리고 다시 실험을 했을 때, 바로 망가져버리는 결과가 있었습니다. → 이러한 실험 결과를 통해 알 수 있는 점은 사람은 심리적으로 망가져 있는 것을 보면 아닌 것에 비해 더 막 다루어도 된다고 생각하는 경향이 있다. 코드 작업과 깨진 창문과의 관계..
유스케이스 역할 살펴보기입력을 받는다.비즈니스 규칙을 검증한다.모델 상태를 조작한다.출력을 반환한다.유스케이스는 인커밍 어댑터로부터 입력을 받습니다.이 단계는 “입력 유효성 검증”을 하는 것이 아니라, Controller에서 받은 입력값을 유스케이스 서비스에 맞게 매핑하여 전달합니다. (SendMoneyRequest → SendMoneyCommand) 유스케이스는 비즈니스 규칙을 검증할 책임이 있으며, 비즈니스 규칙을 충족하면 유스케이스는 입력을 기반으로 모델의 상태를 변형합니다.일반적으로 도메인 객체의 상태를 바꾸고, 영속성 어댑터를 통해 구현된 포트로 이 상태를 전달하여 데이터베이스의 값을 변경하거나 저장합니다. (하나의 유스케이스는 여러 개의 아웃고잉 어댑터를 호출할 수 있습니다.)아웃고인 어댑터에..
계층형 아키텍처 구조 - web, domain, persistence 로 나누기최적화된 구조가 아닌 이유애플리케이션의 기능 조각이나 특성을 구분 짓는 패키지 경계가 없다.web 패키지에 UserController 추가, domain 패키지에 UserService, UserRepository, User 추가, persistence 패키지에 UserRepositoryImpl을 추가하게 되어 세부 기능과 역할별로 구분하기 어렵다.애플리케이션이 어떤 유스케이스들을 제공하는지 파악할 수 없다.AccountService, AccountController 처럼 작성하게 되면 어떤 유스케이스를 구현했는지 파악하기 어렵다.특정 기능을 찾기 위해서 어떤 서비스가 이를 구현했는지를 추측해야 하고, 해당 서비스 내의 어떤 메..
SRP - 단일 책임 원칙단일 책임 원칙은 거의 대다수가 “하나의 컴포넌트는 오로지 한 가지 일만 해야 한다”라고 알고 있다.하지만, SOLID에 S 단일 책임 원칙의 실제 정의는 “컴포넌트를 변경하는 이유는 오직 하나뿐이어야 한다”이다. SOLID를 공부하면서 나도 단일 책임 원칙은 하나의 일만 수행해야 한다라고만 알고 있었는데, 해당 책을 읽으면서 컴포넌트를 변경해야 하는 이유가 하나여야 한다는 정의가 좀 더 알맞는다고 생각이 들었다. 변경해야 하는 이유가 하나인 것은 즉, 하나의 일만 수행한다는 것을 의미한다.! 컴포넌트 A는 다른 모든 컴포넌트에 의존하고 있어서 다른 컴포넌트에 변경이 생길 때 같이 변경되어야 한다.컴포넌트 A는 하나의 역할만 수행하는 게 아니라, 여러 역할을 수행하고 있다.여러 ..
