AOP는 Ioc/DI 와 PSA와 더불어 스프링의 3대 기반 기술이다. OOP를 대체하려는 것처럼 보이는 AOP가 필연적으로 등장할 수 밖에 없던 배경과 스프링이 그것을 도입한 이유, AOP를 적용하면 얻을 수 있는 장점이 무엇인지에 대해 충분히 이해해보자.
스프링에서 가장 인기 있는 AOP 적용 대상은 선언적 트랜잭션 기능이다. 서비스 추상화를 통해 트랜잭션에 대한 많은 기능을 해결했는데 AOP를 이용해 더욱 세련되고 깔끔한 방식으로 바꿔보자. 그 과정에서 스프링이 AOP를 도입해야했던 이유를 알아보자.
스프링이 제공하는 깔끔한 트랜잭션 인터페이스를 썼음에도 불구하고 비즈니스 로직이 주인이어야할 메소드 안에 이름도 길고 무시무시하게 생긴 트랜잭션 코드가 더 많은 자리를 차지하는 것이 못마땅하다. 하지만 트랜잭션의 경계는 비지니스 로직 전 후에 설정돼야하는 것이 분명하니 UserService 메소드에 안둘수가 없다..
트랜잭션 처리하는 로직과 비즈니스 로직 사이에 주고받는 정보가 없으니 비즈니스 로직을 메소드로 분리해주면 좀 더 깔끔해진다.
1.1에서 메소드로 분리했지만 UserService안에 트랜잭션 관련 코드가 자리잡고 있으니 아직 불만이 남아있다.
UserService에서 트랜잭션 코드를 분리할 수 있는 방법은 없을까?