좋은 설계는 제약이 있는 것이다

@Around만 있으면 되는데 왜? 이렇게 제약을 두는가? 제약은 실수를 미연에 방지한다. 

일종에 가이드 역할을 한다.

 

만약 @Around를 사용했는데, 중간에 다른 개발자가 해당 코드(Object result = joinPoint.proceed();)를 수정해서 후출하지 않았다면?  큰 장애가 발생했을 것이다. 

 

처음부터 @Before 를 사용했다면 이런 문제 자체가 발생하지 않는다. 

제약 덕분에 역할이 명확해진다. 다른 개발자도 이 코드를 보고 고민해야 하는 범위가 줄어들고 코드의 의도도 파악하기 쉽다. 

 

@Around("hello.aop.order.aop.Pointcuts.orderAndService()")
    public Object doTransaction(ProceedingJoinPoint joinPoint) throws Throwable{
        try{
            //@Before
            log.info("[트랜잭션 시작] {}", joinPoint.getSignature());
            Object result = joinPoint.proceed();
            //@AfterReturning
            log.info("[트랜잭션 커밋] {}", joinPoint.getSignature());
            return result;
        }catch(Exception e){
            //@AfterThrowing
            log.info("[트랜잭션 롤백] {}", joinPoint.getSignature());
            throw e;
        }finally{
            //@After
            log.info("[리소스 릴리즈] {}", joinPoint.getSignature());
        }
    }

 @Before("hello.aop.order.aop.Pointcuts.orderAndService()")
    public void doBefore(JoinPoint joinPoint){
        log.info("[before] {}", joinPoint.getSignature());
    }