대규모 개발쯤 되면 기본적으로 트랜잭션 스크립트와 같은 로직 주도 설계로 만드는 경우가 많지만, 최근 시스템 개발은 비즈니스 로직이 복잡한 것도 많다. 또한 웹 애플리케이션의 생명 주기를 고려해 상속 등 객체 지향의 이점을 살린 변경이나 확장의 용이성이 필요할 때도 많다.
그럴 때 트랜잭션 스크립트 비즈니스 로직이 된다. 이를 방지하려면 도메인 패키지의 클래스에 도메인 로직을 두는 도메인 모델로 비즈니스 로직 층을 만드는 것이 좋다.
다만 실제 개발에서는 도메인 모델을 이용해 아름답게 만드는데 너무 집착하다가 동작하지도 않고 납품할 수도 없는 애플리케이션을 만드는 일만은 피하자. 현실에서는 도메인 모델로 만들다 한계를 느끼면 재빨리 트랜잭션 스크립트로 전환하는 두뇌의 유연성도 필요하다.
그리고 앞으로를 위해 한 가지 더 주의해야 할 것이 있다. 스프링이 중심이 되는 DIxAOP 컨테이너는 도메인 모델의 구축이나 관리에 별로 도움이 되지 않는다는 점이다. 도메인 모델은 로직을 가진 메서드뿐만 아니라 속성, 즉 값을 가진 인스턴스로서 생성되지만, 값을 가진 인스턴스는 RDB에서 읽어와서 RDB와의 통신으로 관리된다. 다시 말해, 도메인의 생성과 관리는 DIxAOP 컨테이너가 아닌 데이터 엑세스 층의 구조에 의존한다. 바꾸어 말하면, 스프링은 도메인 모델을 제외한 모든 것에 대응할 수 있는 프레임워크이다.
도메인 주도 설계(DDD: Domain-Driven Design) : 에릭 에반스가 정리한 도메인 모델을 생성하는 패턴과 철학
'Study > Spring' 카테고리의 다른 글
[Spring Framework] 데이터 액세스 층의 역할 (0) | 2019.08.03 |
---|---|
[Spring Framework] 트랜잭션 관리 (0) | 2019.08.03 |
[Spring Framework] 비즈니스 로직 층의 패턴 (0) | 2019.08.03 |
[Spring Framework] 비즈니스 로직 층의 역할 (0) | 2019.08.03 |
[Spring Framework] 다양화되는 사용자 인터페이스 (0) | 2019.08.03 |