TDD, DDD, MSA

TDD: Test Driven Development, 테스트 주도 개발

테스트 주도 개발은 설계 이후 코드 개발 및 테스트 케이스를 작성하는 방식이 아닌 테스트 케이스를 작성한 후 실제 코드를 개발하여 리팩토링 하는 절차를 따른다. 이런 이유로 TDD를 Test First Development라고도 한다.

1. RED: 테스트 실패

   구체적인 하나의 기능에 대한 하나의 테스트를 추가하고 테스트가 실패하는지 확인한다.

   테스트가 실패해야 해당 테스트가 신뢰성 있다고 할 수 있는데 이때 실패 이유에는 테스트 코드의 문제가 없어야 한다.

2. GREEN: 테스트 성공

   모든 테스트에 대해 코드가 성공하도록 코드를 수정하는 단계이다.

   테스트 성공을 위해 최소한의 코드 변경이 이루어져야 하는데 필요 이상으로 코드가 변경되면 다른 단계에 악영향을 끼칠 수 있기 때문이다.

3. REFACTOR: 리팩토링

   코드 베이스를 정리하고 가독성, 적용성, 성능을 고려해 구현 설계를 개선한다.

TDD 특징

• 코드가 완성되고 개발자 손을 떠나기 전에 빠른 피드백이 가능하다.
• 사용자에게 도달하기 전에 테스트를 통해 문제를 알 수 있고 코드의 불안정성을 개선하고 생산성을 높일 수 있다.
• 개발 과정이 테스트 코드로 남기 때문에 과거 의사 결정을 확인하기 쉽다.
• 테스트를 만들어야 하는 만큼 그냥 개발할 때보다 더 많은 시간과 리소스를 필요로 한다.
• 시간이 지날수록 비용이 일정하게 유지되어 장기적으로 봤을 때 유리하다고 할 수 있다.
  
  
  
  
  
  
  
  

DDD: Domain Driven Development, 도메인 주도 개발

• 여러 도메인들의 상호작용을 통해 설계하는 방법
• 도메인을 서비스별로 분리하여 개발하는 것이 핵심이다.
• 직접적으로는 서로 다른 도메인 영역에 영향을 끼칠 수 없고 API 호출을 사용하면 도메인들은 서로 완전하게 분리되고 변경과 확장에 대해 유리해진다.

3단계

1. Application Layer

   주로 도메인과 Repository를 바탕으로 실제 서비스(API)를 제공하는 계층

2. Domain Layer

   Entity, ValueObject를 활용하여 도메인 로직이 진행되는 계층

   → primary key를 바탕으로 객체의 정체성을 부여한다.

   → 상태를 바탕으로 객체의 정체성을 부여한다.

3. Infrastructure Layer

   외부와의 통신을 담당하는 계층

MSA: MicroService Architecture, 마이크로서비스 아키텍처

작고 독립적으로 배포 가능한 각각의 기능을 수행하는 서비스로 구성된 프레임워크

완전히 독립적으로 배포가 가능하고 다른 기술 스택이 사용 가능한 단일 사업 영역에 초점을 둔다.

MSA 특징

1. API를 통해서만 상호작용할 수 있다.

   서비스의 end-point(접근점)을 API 형태로 외부에 노출하고 실질적인 세부 사항은 모두 추상화한다.

   내부의 구현 로직, 아키텍처와 프로그래밍 언어, 데이터베이스, 품질 유지 체계와 같은 기술적인 사항들은 서비스 API에 의해 철저하게 가려진다.

2. 각각의 서비스는 모듈화가 되어있으며 이러한 모듈끼리는 RPC, message-driven API 등을 이용하여 통신한다.

   MSA는 각각 개별의 서비스 개발을 빠르게 하며 유지보수도 쉽게할 수 있도록 한다.

3. 마이크로 서비스는 서비스별로 독립적인 배포가 가능하다.

   지속적인 배포 CD도 모놀로식에 비해 가볍게 할 수 있다.

4. 모놀리식에 비해 상대적으로 많이 복잡하다.

   서비스가 모두 분산되어 있기 때문에 개발자는 내부 시스템의 통신을 어떻게 가져가야 할지 정해야 한다.

   통신의 장애와 서버의 부하 등이 있을 경우 어떻게 트랜잭션을 유지할 지 결정하고 구현해야 한다.

5. 통합 테스트가 어렵다.

   개발 환경과 실제 운영환경을 동일하게 가져가는 것이 쉽지 않다.