[노개북] 클린코드 24일차 - 노마드 코더

노마드코더

 

 

😀 책에서 기억하고 싶은 내용을 써보세요.

• 순수 자바 AOP 프레임워크
  • 순수 자바 관점을 구현하는 스프링 AOP, JBoss AOP 등과 같은 여러 자바 프레임워크는
    내부적으로 프록시를 사용한다.
    * '순수 자바' 란 AspectJ를 사용하지 않는다는 뜻이다.
  • 스프링은 비즈니스 논리를 POJO로 구현한다.
  • POJO는 순수하게 도메인에 초점이 맞춘다.
  • POJO는 엔터프라이즈 프레임워크에 (그리고 다른 도메인에도) 의존하지 않는다.
    따라서 테스트가 개념적으로 더 쉽고 간단하다.
  • 상대적으로 단순하기 때문에 사용자 스토리를 올바로 구현하기 쉬우며 미래 스토리에 맞춰
    코드를 보수하고 개선하기 편하다.
• 애플리케이션 도메인 논리를 POJO로 작성할 수 있다면, 즉 코드 수준에서 아키텍처 관심사를 분리할 수 있다면,
  진정한 테스트 주도 아키텍처 구축이 가능해진다.
• 초창기 EJB 아키텍처는 기술을 너무 많이 넣느라 관심사를 제대로 분리하지 못했던 유명한 API 중 하나다.
  • 좋은 API는 걸리적거리지 않아야 한다. 그래야 팀이 창의적인 노력을 사용자 스토리에 집중한다.
    그리하지 않으면 아키텍처에 발이 묶여 고객에게 최적의 가치를 효율적으로 제공하지 못한다.
• 도메인 논리가 흐려지면 제품 품질이 떨어진다.
  • 버그가 숨어들기 쉬워지고, 스토리를 구현하기 어려워지는 탓이다.
  • 기민성이 떨어지면 생산성이 낮아져 TDD가 제공하는 장점이 사라진다.
• 모든 추상화 단계에서 의도는 명확히 표현해야 한다.
  • 그러려면 POJO를 작성하고 관점 혹은 관점과 유사한 메커니즘을 사용해 각 구현 관심사를 분리해야 한다.

 

 

시스템을 설계하든 개별 모듈을 설계하든,
실제로 돌아가는 가장 단순한 수단을 사용해야 한다는 사실을 명심하자.

 

 

 

 

🤔 오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요.

1. 도메인 설계를 왜 POJO로 하는지 개념이 확실하게 잡히지 않았었습니다.
   => 이번 챕터를 읽으면서 그 이유에 대해서 알 수 있었습니다.
2. 설계가 잘못되면 테스트가 힘들다는 것은 알고 있었는데 정확한 이유를 몰랐었습니다.
   => 도메인 논리를 POJO로 작성하면서 관심사 분리할 수 있다는 이점이 있었습니다.

 

 

 

🔎 궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요. 

• 횡단 관심사란?
  • 핵심적인 기능이 아닌 중간중간 삽입되어야 할 기능들 관심들을 횡단관심사라고 한다.
    ex) 로깅, 보안, 트랜잭션 처리 등 비즈니스 핵심적인 기능이 아닌 다양한 횡단 관심이 발생할 수 있다.
  • 다른 관심사에 영향을 미치는 프로그램의 Aspect이다. 이 관심사들은 디자인과 구현 면에서 시스템의 나머지 부분으로부터 깨끗이 분해되지 못하는 경우가 있을 수 있으며 분산(코드 중복)되거나 얽히는(시스템 간의 상단한 의존성 존재) 일이 일어날 수 있다. - 위키백과 -
  • 여러 비즈니스 로직이 수행될 때 서로 중복되는 로직이 존재하는지에 대한 관심사.

 

• 영속성(persistence) 정보란?
  
  • 영속성은 데이터를 생성한 프로그램의 실행이 종료되더라도 사라지지 않는 데이터의 특성을 의미한다.
  • 영속성은 파일 시스템, 관계형 데이터베이스 혹은 객체 데이터베이스 등을 활용하여 구현한다.
  • 영속성을 갖지 않는 데이터는 단지 메모리에서만 존재하기 때문에 프로그램을 종료하면 모두 잃어버리게 된다.
  • 영속성은 특정 데이터 구조를 이전 상태로 복원할 수 있게 해주어 프로그램의 종료와 재개를 자유롭게 해준다.

 

 

 

👀 소감 3줄 요약

• 도메인 논리를 POJO로 작성하고, 코드 수준에서 아키텍처 관심사를 분리할 수 있다면,
  진정한 테스트 주도 아키텍처 구축이 가능해진다.
• 도메인 논리가 흐려지면 제품 품질이 떨어진다.
• 모든 추상화 단계에서 의도는 명확히 표현해야 한다.