AOP 학습 일정 1

2주간 : Spring Reference 6장 공부
영근님과 온라인에서 발표

6. Aspect Oriented Programming with Spring


6.1. Introduction


6.1.1. AOP concepts
6.1.2. Spring AOP capabilities and goals
6.1.3. AOP Proxies in Spring

6.2. @AspectJ support


6.2.1. Enabling @AspectJ Support
6.2.2. Declaring an aspect
6.2.3. Declaring a pointcut


6.2.3.1. Supported Pointcut Designators
6.2.3.2. Combining pointcut expressions
6.2.3.3. Sharing common pointcut definitions
6.2.3.4. Examples

6.2.4. Declaring advice


6.2.4.1. Before advice
6.2.4.2. After returning advice
6.2.4.3. After throwing advice
6.2.4.4. After (finally) advice
6.2.4.5. Around advice
6.2.4.6. Advice parameters
6.2.4.7. Advice ordering

6.2.5. Introductions
6.2.6. Aspect instantiation models
6.2.7. Example

6.3. Schema-based AOP support


6.3.1. Declaring an aspect
6.3.2. Declaring a pointcut
6.3.3. Declaring advice


6.3.3.1. Before advice
6.3.3.2. After returning advice
6.3.3.3. After throwing advice
6.3.3.4. After (finally) advice
6.3.3.5. Around advice
6.3.3.6. Advice parameters
6.3.3.7. Advice ordering

6.3.4. Introductions
6.3.5. Aspect instantiation models
6.3.6. Advisors
6.3.7. Example

6.4. Choosing which AOP declaration style to use


6.4.1. Spring AOP or full AspectJ?
6.4.2. @AspectJ or XML for Spring AOP?

6.5. Mixing aspect types
6.6. Proxying mechanisms


6.6.1. Understanding AOP proxies

6.7. Programmatic creation of @AspectJ Proxies
6.8. Using AspectJ with Spring applications


6.8.1. Using AspectJ to dependency inject domain objects with Spring


6.8.1.1. Unit testing @Configurable objects
6.8.1.2. Working with multiple application contexts

6.8.2. Other Spring aspects for AspectJ
6.8.3. Configuring AspectJ aspects using Spring IoC
6.8.4. Using AspectJ Load-time weaving (LTW) with Spring applications

6.9. Further Resources

Building Domain Knowledge

비행기 모니터링 시스템을 구축하려고 한다.
특정 지역에 떠있는 모든 비행기들의 루트를 파악하여 충돌할 가능성이 있는지 나타내는 모니터링 시스템을 구축하는 것이 프로젝트의 목표다.

앞에서 얘기 했듯이 도메인을 이해하는 것부터 시작해야 한다

이 분야 도메인 전문가는 비행기 통제사다. 통제사와 대화를 하는 도중 비행기 이륙과 착륙에 대한 이야기를 많이 듣게 되었다. 그리고 실제 충돌이 이착륙 대기 중일 때 발생할 위험이 있다고 한다.

통제사와 당신은 모든 비행기가 목적지와 출발지가 있다는데에 동의했다. 그래서 다음과 같이 그렸다.

bl120.bmp
실제 비행기가 공중에 있을 때는 어떤 일이 벌어질지 물어본다. 통제사는 각각의 비행기에는 정해진 비행로가 있다고 한다. 대화를 좀더 듣다보니 경로(Route)라는 흥미로운 단어를 들었다. 이 것이 실제 비행중에 가장 중요하다고 생각했고 비행기가 목적지와 출발지와 직접적으로 연관관계를 갖는 것이 아니라 경로(Route)와 연관을 맺고 이 경로가 목적지와 출발지와 연관을 맺도록 하는 좀 더 명확한 표현 같다.
bl121.bmp
좀 더 이야기를 해보니 이 경로는 여러 세부 경로로 나뉘어져 있다는 것을 듣게 된다. 즉 경로가 고정된 포인트로 이루어 진 것으로 파악이 되며 목적지와 출발지는 그 고정된 포인트 중 두 개로 파악할 수 있다.
bl122.bmp고정된 위치는 3차원으로 표기 할 수 있다.(경도, 위도, 고도?) 하지만 통제사는 비행기를 지구 표면의 평면으로 투사한 곳에 점으로 인식하고 있다는 것을 알게 됐다. 따라서 2차원 점(경도 , 위도만?)으로 표현되도록 수정하였다.
bl123.bmp

여기까지 진행 한 것을 살펴보면 굉장히 많은 시간을 소비하는 것처럼 보이고 실제로도 그렇치만 당연히 이렇게 해야만 한다. 소프트웨어의 최종 목적은 현실의 도메인과 관련된 비즈니스 문제를 해결하는 것이기 때문에 도메인에 익숙해 져야한다.

What Is Domain-Driven Design

소프트웨어 개발은 진짜 세상에 존재하는 프로세스를 자동화 시킨 것 또는 현실의 비즈니스 문제에 대한 솔루션을 제공한다.

좋은 소프트웨어를 개발하기 위해서는 그 소프트웨어가 무엇을 하는지 완벽히 알아야 한다.

소프트웨어 프로젝트를 시작할 때 도메인에 집중해야 한다. 도메인에 깊게 뿌리를 두지 않은 소프트웨어는 시간이 갈 수록 변화에 잘 적응할 수 없다.

추상화란? 도메인에 대한 모델이다. Eric Evans는 도메인 모델은 특정 다이어그램이 아니라고 한다. 영어 문장이나 잘 작성된 코드 처럼 도메인을 표현할 수 있고 의사소통이 가능한 다이어그램이다.

모델에 무엇을 표현하고 무엇을 표현하지 말지 정해야 한다.
다른 사람과 의사소통 할 수 있도록 표현이 가능해야 한다. 그래픽을 사용하는 방법과 글로 표현하는 방법이 있다.
=> We need to communicate the model

모델을 만든 뒤에는 코드 설계(code design)를 시작할 수 있다. 소프트웨어 설계는 큰 그림 부터 그리고 코드 설계는 세밀한 부분부터 그린다.
=> 좋은 코드 설계 없이 만들어낸 최종 산출물은 좋을 수 없다.

Waterfall 과 Agile 방법론의 단점들
Waterfall : feedback이 없다.
Agile : analysis paralysis(아무도 설계에 대한 결정을 하려 들지 않는다.), 초기에 전체 윤곽을 파악하기 힘들다.
=> DDD는 적용이 되면 어떤 개발 공정의 능력도 향상 시킬 수 있다.

DDD conbines design and development practice, and shows how design and development can work together to create a better solution.

DDD Jedi 선수작업

ORM : http://www.agiledata.org/essays/mappingObjects.html#MapHierarchyToTable

AOP : Spring Reference 6장, 7장 정리. 하다가 모르는 것만 Aspectj in action 참조.
* Proxy 기반과 Aspect 기반의 차이점
* Spring에서 AOP 어떻게 쓰는가 (reference 참조)
* 어떻게 쓰는지, 기본 개념 등이 파악되면.. 언제 어떻게 쓰는 것이 좋은가.
* AOP를 써서 어떨 때 어떻게 좋아졌는지 보여주는 예제 소스 코드 위주로 공부.