Whiteship's Note

@Configurable 사용해야 하는 이유

Spring/Chapter 6 : 2007.11.22 21:14


DTO를 공부하다가 들었던 의문.. 그동안 내가 만들었던 DO들의 빈약함(Anemic Domain Model)에 대해 명쾌하고 깔끔하게 정리를 해주신 글을 발견했습니다. 그리고 그 대안으로 Rich 또는 Smart DO 그리고 DDD로 이어지는 흐름도 좋은 글입니다. 머리가 맑아지는 동시에 공부할 것들로 머리가 꽉차게 되는 그런 글이기도 합니다.

스프링프레임워크와 DDD(Driven Driven Design)

기존에는 도메인 객체를 모든 레이어에 걸쳐서 사용했었습니다. 그런데 DDD를 하면 도메인이 서비스 계층과 리파지토리 계층 사이에 끼이게 됩니다. 이제 하나의 계층으로 자리를 잡게 되는 것이죠.
사용자 삽입 이미지
출처: https://www.dbguide.net/know/know102001.jsp?mode=view&divcateno=9&divcateno_=9&pg=1&idx=3229

이렇게 되면 도메인 객체에 무언가(DAO나 Repository) 주입시켜주어야 합니다. 그런데.. 이 주입시키는 일 Dependency Injection을 사용하려면 스프링이 관리하는 bean이어야 합니다. 즉 스프링 설정 파일에 도메인 객체가 bean으로 등록되어 있어야 한다는 것이죠. 하지만 문제는 도메인 객체들은 bean으로 설정하여 종속성을 관리할 객체로는 적당하지 않습니다.

이 객체들의 생성을 스프링 컨테이너가 관리할 수 없습니다. 이 객체들은 애플리케이션 동작 중에 생성되기 때문에, 스프링이 생명주기를 관리할 bean으로 등록하여 사용한다는 것은 말이 안됩니다.

이럴 때 등장하는 녀석이 바로 저 @Configurable 애노테이션 입니다. 이녀석이 붙어있는 클래스를 스프링에 등록해두면, 스프링은 그 객체가 생성될 때 그 객체가 필요로 하는 bean들을 주입해 줍니다. 엄청나죠. 이런 일이 어떻게 가능할까요. 바로 AOP 때문에 가능하죠. method 호출 Joinpoint만을 지원하는 스프링 AOP로는 이런 일을 할 수 없습니다. 생성자 실행 Joinpoint를 지원하는 AspectJ가 할 수 있는 일이죠.

그래서 @Configurable을 사용하려면 AsepctJ Load Time Weaver가 필요합니다.

결국 스토리는 이렇게 됩니다.
  1. DDD를 하고싶어. (도메인 객체가 DAO를 필요로 하고 있어.)
  2. @Configurable을 사용해야 겠다. (애플리케이션 실행 도중 생기는 객체도 스프링에서 관리할꺼야.)
  3. LTW가 필요하구나.
아니면 간단하게 다음과 같이 해도 되죠.
  1. DDD를 하고싶어. (도메인 객체가 DAO를 필요로 하고 있어.)
  2. 도메인 생성자에서 new 써주지뭐.
아래의 스토리가 더 짧고 간단합니다. 그런데도 저는 첫 번째 스토리대로 하고 싶습니다. 왜냐면, 스프링이 도중에 생겨난 객체들 까지 관리하게 되면, 그 객체들(풍성해진 도메인)에 스프링의 DI와 AOP를 적용할 수 있기 때문이죠. 아래 스토리대로 하면, 도메인 객체가 참조하는 DAO가 바뀌면 소스코드를 매번 바꿔줘야 되겠죠. 그리고 다른 코드는 전부 DI랑 AOP 사용해놓고 도메인 계층만 왕따 시키는 것도 아니고.. 좀 그렇차나요.ㅎㅎ;

그래서.. 좀전까지 @Configurable과 LTW랑 팀을 맺고 저랑 2:1로 씨름을 하고 있었습니다. 제가 졌습니다. 오늘은..-_-;; 잘 안 되더라구요. Eclipse에서 JVM 아규먼트 설정해 주는게 틀렸나.. 왜 그러징;;

'Spring > Chapter 6' 카테고리의 다른 글

CGLIB 프록시 제약 사항 테스트.  (2) 2008.10.02
@Configurable + 톰캣  (2) 2008.01.16
@Configurable + @Entity  (0) 2008.01.16
@Configurable 사용하기  (6) 2007.11.26
@Configurable 왜이리 안 되지;  (2) 2007.11.23
@Configurable 사용해야 하는 이유  (5) 2007.11.22
6.6. Proxying mechanisms  (0) 2007.04.06
6.4. Choosing which AOP declaration style to use  (0) 2007.04.06
Schema 기반 Introduction  (0) 2007.04.06
Schema 기반 Advice parameters  (0) 2007.04.06
<aop:around> 어드바이스 예제  (0) 2007.04.06
top

  1. Favicon of http://toby.epril.com BlogIcon 토비 2007.11.23 10:39 PERM. MOD/DEL REPLY

    어디서 많이 보던 글이네...

    Favicon of https://whiteship.tistory.com BlogIcon 기선 2007.11.23 13:28 신고 PERM MOD/DEL

    ㅎㅎ좋은 글 감사합니다.

  2. Favicon of http://openframework.or.kr/blog/ BlogIcon 이동국 2007.11.26 23:04 PERM. MOD/DEL REPLY

    LWT 가 아니라 LTW 아닌가요..??
    그리고 제가 도메인 모델에 대해 정확한 개념이 없어서 그런데 DAO나 Repository를 삽입한다면 기존의 서비스 계층과 도메인 계층간의 차이가 어떻게 되는건가요..??

    Favicon of https://whiteship.tistory.com BlogIcon 기선 2007.11.27 09:32 신고 PERM MOD/DEL

    LTW가 맞습니다. 오타에요. 감사합니다. 글 쓸때도 자꾸 틀리더니 결국 오타로 남았네요. :)

    저도 요즘 Domain Model, Active Record, Service Layer 이 들 때문에 머리가 좀 복잡한데요.

    Patterns of Enterprise Application Architecture 2장을 보시면 도메인 로직을 어디에 두느냐에 대한 이야기가 있습니다.

    2장에 Service Layer 부분을 읽어보시면 트랜잭션이나 보안과 관련된 코드(이 것은 Aspect로 처리할 수 있는 것들인데, 그럼 Aspect들도 Service 계층의 일부로 생각해야겠구나. 라고 생각해봤습니다.)를 두기도 좋은 곳이며, use-case controller로 사용할 수 있다고하는 이야기도 있으며, 도메인 계층의 API를 사용하기 위한 Facade로 활용할 수도 있겠다는 이야기가 있습니다.

    하지만 저자는 서비스 계층을 별로 사용하지 않는 것 같았습니다. 정말 필요하지 않는 이상 거의 사용하지 않는다고 합니다.

    복잡해서 걍 간단하게 머리에 정리해 둔 건 다음과 같습니다.

    도메인 계층에 비즈니스 로직을 넣어 두고, 서비스 계층에서는 Use-Case에 기반해서 도메인 계층의 Facade 정도로 사용하면 될 것 같다는 것입니다. Aspect들도 서비스 계층에 둬도 될 것 같구요.

    따라서 뭔가 다르긴 다른듯 합니다.

    Favicon of https://whiteship.tistory.com BlogIcon 기선 2007.11.27 09:49 신고 PERM MOD/DEL

    댓글을 달고나니 동문서답한 기분이네요.

    질문을 다시 생각해보니 이런 것 같네요. (기존의)서비스 계층도 DAO를 사용하고, (이제는)도메인 계층에서 DAO를 사용하면 예전의 서비스 계층과 지금의 도메인 계층의 차이가 무엇이냐? 라는게 질문이시죠?

    DAO를 사용하던 로직만 보면 차이가 없는 것 같습니다. 그냥 해당 로직이 도메인 계층으로 옮겨 간거죠.

    하지만 서비스 계층에 있던 모든 로직을 도메인 객체로 옮겼다고 볼 순 없기 때문에 차이가 있는 것 같습니다. 정확하게는 기존의 서비스 계층에 무엇이 담겨있었느냐에 따라 차이가 있을 것 같습니다.

    위 댓글에서도 언급했었지만 분명 서비스 계층에서 책임질 수 있는 일들이 (있을 수 도)있고 도메인 계층에서 책임질 행동들이 있는 것 같습니다.

    따라서 상황에 따라 기존의 서비스 계층을 도메인 계층이 전부 대체 할 수도 있고, 그러지 않을 수도 있을 것 같습니다.
    -------------------------------------
    ex1) 서비스 계층을 거의 안 사용하고, 꼭 필요할 때만 만들어 쓰다는 저자의 경우라면, 거의 도메인 계층이 서비스 계층을 대체한 상태인.. 즉, 이동국님께서 질문하신대로 거의 같다고 봐도 되는 상황인것 같네요.

    ex2) 그러나 대부분은 Service 계층을 두고 무언가의 용도로 사용하고 있기 때문에(Aspect, 도메인 계층의 Facade, Use-case controller로 등으로), 이럴 때는 같다고 볼 수가 없을 것 같습니다.

    복잡하네요.ㅎㅎㅎ

Write a comment.




: 1 : ··· : 3 : 4 : 5 : 6 : 7 : 8 : 9 : 10 : 11 : ··· : 30 :