네이키드 오브젝트는 도메인 객체에 비즈니스 로직을 캡슐화하고, 사용자 인터페이스를 도메인 객체의 직접적 표현으로 삼아, 도메인 정의로부터 UI를 자동 생성하는 소프트웨어 아키텍처 패턴이다.
위키백과, 우리 모두의 백과사전에서
네이키드 오브젝트(Naked objects)는 소프트웨어 공학에서 사용되는 아키텍처 패턴이다. 이는 세 가지 원칙으로 정의된다:
네이키드 오브젝트 패턴의 혁신적인 특징은 1번과 2번 원칙을 결합한 3번째 원칙에서 나온다:
네이키드 오브젝트 패턴은 Richard Pawson의 박사 학위 논문[1]에서 처음으로 공식적으로 기술되었으며, 여기에는 예를 들어 Morphic 사용자 인터페이스 등 이 패턴의 선행 개념과 영감에 대한 조사도 포함되어 있다.
이 패턴을 구현한 최초의 완전한 오픈 소스 프레임워크의 이름도 Naked Objects였다.[2] 2021년 Pawson은 동일한 패턴을 객체 지향 프로그래밍 패러다임의 대안으로 함수형 프로그래밍 패러다임에 적용하여, Naked Functions라 불리는 네이키드 오브젝트 프레임워크의 변형을 만들었다고 발표했다.[3]
Pawson의 논문[1]은 이 패턴의 네 가지 장점을 주장한다:
아일랜드의 사회보호부(Department of Social Protection, DSP, 이전 명칭은 Department for Social and Family Affairs)는 네이키드 오브젝트 패턴을 사용하여 일련의 엔터프라이즈 애플리케이션을 구축했다. 서비스 전달 현대화(SDM) 프로그램의 일환으로, DSP는 계획된 새로운 비즈니스 요구를 충족하고 장기적으로 더 큰 민첩성을 제공하기 위해 새로운 엔터프라이즈 아키텍처를 설계했다. 네이키드 오브젝트 패턴은 SDM 아키텍처의 핵심 요소를 이룬다.[4] 2002년 11월, DSP는 아동 수당 관리에 사용되던 기존 시스템을 대체하는 새로운 애플리케이션을 가동했다. 이는 전 세계적으로 네이키드 오브젝트 패턴이 실제 운영에 적용된 최초의 사례로 여겨진다. 이 첫 애플리케이션을 구축하는 과정에서의 DSP의 경험, 그리고 급진적인 사용자 인터페이스에 대한 사용자들의 반응은 Pawson의 논문[1]과 2011년 QCon London에서의 발표[5]에 광범위하게 문서화되어 있다.
DSP 경험의 더 눈에 띄는 측면 중 하나는 네이키드 오브젝트 기법이 매우 적극적인 재사용을 가능하게 했다는 점이다. 예를 들어 Customer와 같은 도메인 객체를 한 ‘애플리케이션’을 위해 정의해 두면, 최소한의 미세 조정과 추가만으로 다른 곳에서도 쉽게 재사용(실제로 재사용됨)할 수 있었다. 이는 재사용이 사일로화된 시스템을 타파하는 강력한 기법으로 여겨지는 정부 부문에서 이 접근법이 선호되는 방식이 될 수 있음을 시사한다. 영국의 ‘변혁적 정부(Transformational Government)’ 정책은 새로운 정부 시스템이 다른 정부 시스템 구성요소를 소비하고 또 다른 이들이 사용할 수 있도록 새로운 구성요소를 제공하도록, 재사용을 표준 요건으로 삼기를 특히 바란다. 이러한 재사용은 흔히 서비스 관점에서 논의되지만, 객체 역시 동일하게 강력한 접근이 될 수 있다.
DSP의 초기 ‘네이키드 오브젝트 아키텍처’는 외부 계약자에 의해 개발되었으나[6], 이후 Naked Objects Framework를 중심으로 아키텍처가 재구성되었고, 이는 네이키드 오브젝트를 사용하여 구축될 향후 애플리케이션 개발의 기반이 되었다는 사실이 4년간의 추가 애플리케이션 구축을 위한 입찰 요청서에서 확인되었다.[7]
[편집]
네이키드 오브젝트 패턴은 다음을 포함한 여러 다른 학문/트렌드와 관련이 있다:
객체 저장 메커니즘 객체-관계 매핑(ORM), 오브젝트 데이터베이스, 오브젝트 퍼시스턴스는 모두 도메인 객체 아래에 전통적인 데이터 액세스 계층을 작성할 필요를 제거하는 데 관심이 있다. 이러한 패턴은 도메인 객체 위의 계층을 작성할 필요를 없애는 데 관심이 있는 네이키드 오브젝트 패턴과 상보적이며 잠재적으로 시너지를 낸다.
애자일 소프트웨어 개발 네이키드 오브젝트는 다양한 방식으로 애자일 개발 방법론의 흐름과 양립하며, 특히 미세한 단위의 반복적 개발과 잘 맞는다. (위에서 설명한) DSP의 경험은 아마도 전 세계 공공 부문 조직 내에서 애자일 소프트웨어 개발 기법이 가장 대규모로 적용된 사례였을 것이다.[8]
도메인 주도 설계(DDD) 도메인(객체) 모델을 진화시키면서 요구 사항을 탐색하는 수단으로 활용해야 한다는 생각이다(그 반대가 아니라). 네이키드 오브젝트 시스템이 사용자 인터페이스와 도메인 모델 간의 직접적인 대응을 강제한다는 사실은 도메인 주도 설계를 시도하기 쉽게 만들고, 그 이점도 더 분명하게 보여 준다.[9]
모델 주도 아키텍처(MDA) 네이키드 오브젝트는 엄밀한 정의의 MDA에는 부합하지 않지만, 많은 동일한 목표를 공유한다. Dan Haywood는 네이키드 오브젝트가 그 목표를 달성하는 데 더 효과적인 접근이라고 주장했다.[10]
Restful Objects 도메인 객체 모델로부터 RESTful 인터페이스를 생성하기 위한 표준. Restful Objects 명세는 인터페이스가 도메인 모델로부터 반사(reflection) 기반으로 생성되어야 한다고 명시하지는 않지만, 그 가능성은 존재한다.
