DAY 24

🔖 오늘 읽은 범위 : 11. 시스템(205~214p)

🤓 책에서 기억하고 싶은 내용

순수 자바 AOP 프레임워크

• 순수 자바 관점 구현하는 스프링 AOP, JBoss AOP 같은 프레임워크는 내부적으로 프록시 사용
• 스프링은 비즈니스 논리를 POJO로 구현
  • 도메인에 초점을 맞춤
  • 엔터프라이즈 프레임워크에 의존하지 않음
  • 테스트가 쉽고 간단
  • 미래 스토리에 맞춰 코드를 보수하고 개선하기 편함
  • 각 Bean은 마트료쉬카 처럼 중첩으로 감싼다
    • Bank → DAO(접근자객체) → JDBC 드라이버
  • 클라이언트는 Bank 객체 내 getAccount()를 호출한다고 믿지만 실제로는 DECORATOR 객체 집합의 가장 외곽과 통신
  • XML이 장황하고 읽기 어렵지만 명시된 ‘정책’ 이 프록시나 관점 논리보다 단순

AspectJ 관점

• 관심사를 관점으로 분리하는 가장 강력한 도구
• 언어 차원에서 관점을 모듈화 구성으로 지원
• 새 도구를 사용하고 문법고 사용법을 익혀야 하는 단점은 있음
• AspectJ annotation form 은 순수 자바 코드에 자바 5 annotation을 사용해 관점을 정의

테스트 주도 시스템 아키텍처 구축

• APP 도메인 논리를 POJO로 작성 → 코드 수준에서 아키텍처 관심사 분리 → 테스트 주도 아키텍처 구축 가능
• 건축가는 BigDesignUpFront 를 추구하지만 소프트웨어는 단순하고 멋지게 분리된 아키텍처로 프로젝트를 진행해 결과물을 재빨리 출시한 후, 기반을 확장해 나가도 괜찮다

의사 결정을 최적화하라

• 각 분리된 관심사와 모듈에 대해 가장 적합한 사람에게 책임을 맡기라
• 가능한 마지막까지 결정을 미뤄서 정보를 모아 최선의 결정을 내려라

명백한 가치가 있을 때 표준을 현명하게 사용하라

• 때로는 표준을 만드는 시간이 너무 오래 걸려 업계가 기다리지 못한다

시스템은 도메인 특화 언어가 필요하다

• Domain-Specific Langauge: 간단한 스크립트 언어나 표준언어로 구현한 API
• 좋은 DSL은 도메인 개념과 코드 사이의 의사소통 간극을 줄여준다

결론

• 모든 추상화 단계에서 의도는 명확히 표현해야 한다
• POJO를 작성하고 관점으로 각 구현 관심사를 분리해야 한다.
• 시스템이건 개별 모듈이건 돌아가는 가장 단순한 수단을 사용해야 한다

🤔 떠오르는 생각

• 아무래도 큰 시스템의 관점에서 바라 본 챕터였기 때문에 추상적인 내용이 많았고 세부 구현이나 팁에 대한 부분은 다른 챕처에서 진행 될 것으로 보인다. 하지만 개발 경력이 많아질 수록 큰 시스템을 더 잘 분리해야 할 것임은 분명하다.

🔎 질문

📝 소감 3줄 요약

• 건축가는 BigDesignUpFront 를 추구하지만 소프트웨어는 단순하고 멋지게 분리된 아키텍처로 프로젝트를 진행해 결과물을 재빨리 출시한 후, 기반을 확장해 나가도 괜찮다
• POJO를 작성하고 관점으로 각 구현 관심사를 분리해야 한다.
• 시스템이건 개별 모듈이건 돌아가는 가장 단순한 수단을 사용해야 한다