도메인 주도 설계

DDD ( 도메인 주도 설계)는 해당 도메인과 일치하도록 소프트웨어를 모델링하는 데 중점을 둔 소프트웨어 설계 접근 방식이다.^[1]

한 가지 중요한 특징은 소프트웨어 코드의 구조와 언어(클래스 이름, 클래스 메소드, 클래스 변수 )가 비즈니스 도메인의 용어를 일치시켜 나간다는 점이다. 예를 들어 소프트웨어가 대출 응용 프로그램을 처리하는 경우 LoanApplication과 Customer와 같은 클래스와 AcceptOffer와 Withdraw 같은 방법이 있을 수 있다.

DDD는 계속해서 발전하는 모델의 구현에 초점을 맞춘다.^[2]

도메인 주도 설계는 다음 목표를 기반으로 한다.

핵심 도메인 및 도메인 논리에 프로젝트의 주요 초점을 둔다.
도메인 모델에 기반한 복잡한 디자인
특정 도메인의 개념적 모델을 계속해서 개선하기 위해 기술 전문가와 도메인 전문가 간의 창의적인 협력을 한다.

도메인 기반 설계에 대한 비판은 개발자가 일반적으로 모델을 순수하고 유용한 구성으로 유지하기 위해 상당한 양의 격리 및 캡슐화를 구현해야 한다고 주장한다. 도메인 기반 설계는 유지 관리 용이성과 같은 이점을 제공하지만 마이크로소프트는 모델이 도메인에 대한 공통 이해를 공식화하는 데 명확한 이점을 제공하는 복잡한 도메인에만 권장한다.^[3]

이 용어는 에릭 에반스가 2003년에 출판한 동명의 책에서 가져왔다.^[4]

각주[편집]

↑ Millet, Scott; Tune, Nick (2015). 《Patterns, Principles, and Practices of Domain-Driven Design》. Indianapolis: Wrox. ISBN 978-1-118-71470-6.
↑ http://www.domaindrivendesign.org/ |제목=이(가) 없거나 비었음 (도움말).
↑ Microsoft Application Architecture Guide, 2nd Edition. Retrieved from http://msdn.microsoft.com/en-us/library/ee658117.aspx#DomainModelStyle.
↑ Evans, Eric (2004). 《Domain-Driven Design: Tackling Complexity in the Heart of Software》. Boston: Addison-Wesley. ISBN 978-032-112521-7. 2012년 8월 12일에 확인함.

[millet2015-1] Millet, Scott; Tune, Nick (2015). 《Patterns, Principles, and Practices of Domain-Driven Design》. Indianapolis: Wrox. ISBN 978-1-118-71470-6.

[definition-2] ttp://www.domaindrivendesign.org/ |제목=이(가) 없거나 비었음 (도움말).

[3] Microsoft Application Architecture Guide, 2nd Edition. Retrieved from http://msdn.microsoft.com/en-us/library/ee658117.aspx#DomainModelStyle.

[evans2004-4] Evans, Eric (2004). 《Domain-Driven Design: Tackling Complexity in the Heart of Software》. Boston: Addison-Wesley. ISBN 978-032-112521-7. 2012년 8월 12일에 확인함.

[1]

[2]

[3]

[4]