[OOAD] 17. 마이크로서비스 아키텍처와 OOAD

마이크로서비스 경계를 기술 계층(UI/로직/DB)이 아니라 바운디드 컨텍스트로 그으면, 분산된 진흙 덩어리를 피할 수 있습니다. 서비스 분해 전략과 서비스별 데이터 소유권 원칙, 도입 여부를 가르는 판단 기준까지 다룹니다.

[OOAD] 18. 클린 아키텍처와 헥사고날 아키텍처

클린/헥사고날/어니언 아키텍처는 이름이 다를 뿐 '의존성은 항상 안쪽으로'라는 같은 규칙을 말합니다. 클린 아키텍처의 4개 동심원 구조와 경계를 넘는 데이터(DTO) 변환 규칙을 실무 파이썬 코드 예제로 정리합니다.

[OOAD] 19. 이벤트 기반 아키텍처와 CQRS

쓰기와 읽기의 요구사항이 크게 다르면 하나의 모델로 둘 다 만족시키려는 시도 자체가 무리수가 됩니다. CQRS로 모델을 분리하고, 도메인 이벤트와 사가 패턴으로 서비스 간 최종 일관성을 다루는 방법을 상세히 정리합니다.

[OOAD] 20. 레거시 시스템 현대화 전략

레거시를 한 번에 새로 짜는 전면 재작성은 대부분 실패합니다. 스트랭글러 무화과 패턴으로 점진적으로 교체하고, 특성화 테스트로 기존 동작을 고정한 뒤 안전하게 이관하는 전략으로 20편에 걸친 시리즈 여정을 마칩니다.

[UnitTesting] 00. 단위 테스트, 왜 다시 배워야 하는가

테스트가 있어도 프로젝트가 느려지는 이유는 테스트가 없어서가 아니라 잘못된 테스트가 많기 때문입니다. 12편에 걸친 이 시리즈 전체의 동기와 상세 커리큘럼, 각 편이 다음 편에 왜 필요한지까지 자세히 함께 정리합니다.

[UnitTesting] 01. 단위 테스트의 목표: 지속 가능한 성장

단위 테스트의 목표는 버그를 줄이는 것이 아니라 프로젝트의 지속 가능한 성장을 가능하게 하는 것입니다. 좋은 테스트와 나쁜 테스트를 가르는 기준, 코드·분기 커버리지 지표의 함정을 실제 코드 예제로 자세히 다룹니다.

[UnitTesting] 02. 단위 테스트란 무엇인가: 고전파와 런던파

단위 테스트의 정의를 두고 고전파(classicist)와 런던파(mockist)라는 두 학파가 갈립니다. '단위'를 클래스로 볼지 협력 객체 전체로 볼지에 따라 목 사용 전략이 완전히 달라지는 이유를 코드로 다룹니다.

[UnitTesting] 03. 단위 테스트의 구조: AAA 패턴과 픽스처

테스트 하나가 여러 단계를 뒤섞어 서술하면 읽는 사람이 의도를 파악하기 어렵습니다. 준비-실행-검증(AAA) 패턴으로 테스트 구조를 통일하고, 픽스처 재사용 판단 기준과 매개변수화 테스트로 코드 중복을 줄이는 실무적인 방법을 다룹니다.

[UnitTesting] 04. 좋은 단위 테스트를 가르는 4대 요소

회귀 방지, 리팩터링 내성, 빠른 피드백, 유지보수성. 이 4가지 요소로 테스트의 좋고 나쁨을 판단하면, '테스트가 있다/없다'가 아니라 '이 테스트가 값어치를 하는가'를 구체적인 코드 예제로 함께 논의할 수 있습니다.

[UnitTesting] 05. 목과 테스트 취약성

목(mock)은 강력하지만 잘못 쓰면 리팩터링 내성을 가장 빨리 갉아먹는 도구입니다. 목/스텁/페이크의 정확한 구분과, 목을 써도 되는 경계(프로세스 외부 의존성, 관리/비관리 의존성)를 코드 예제로 명확히 다룹니다.