엔터티 또는 비즈니스 계층에 계산 논리를 넣어야합니까?

최근에 간단한 계산을 엔터티 계층에 배치해야하는지 아니면 원시 데이터를 저장하고 계산 논리를 비즈니스 계층에 그대로두기 위해 엔터티가 순수해야하는지에 대한 질문에 직면했습니다.

내 질문은 엔티티 클래스의 속성에서 간단한 계산을 캡슐화하는 것이 합리적인지 여부입니다.

원하는 아키텍처 유형에 따라 다릅니다.

• 도메인 기반 디자인에서는 데이터와 기능을 모두 갖춘 도메인 모델 을 만듭니다 .

이는에 Order기반하여 주문의 총 가격을 반환하는 속성 (또는 방법) 이 있음을 의미 합니다 OrderLines. 은 Order또한 방법을 것 AddOrderItem(Product product, int amount)과는 Order이미이 있는지 확인 할 OrderLine특정 제품에 대한.

이러한 모델에는 Repository데이터 액세스 또는 Factory엔터티 만들기 와 같은 실제 엔터티가 아닌 개체도 있습니다 . 이를 도메인 서비스라고합니다. 응용 프로그램 계층은 도메인 서비스 호출 (예 : 데이터베이스에서 엔티티 검색)을 담당하며 엔티티에서 기능을 실행합니다. 는 Application Layer가능한 한 얇아 야한다.

이 개념에 대해 자세히 설명하는 DDD에 대한 유용한 기사 입니다.

• 빈혈 도메인 모델을 사용할 수도 있습니다 . 즉, 엔티티는 get / set 속성으로 구성되며 동작이 없습니다. 이러한 디자인에서 비즈니스 계층에는 Order가격 계산 및 중복 확인과 같은 동작이 포함됩니다 OrderLines.

빈혈 도메인 모델이 나쁜지 다른 의견이 있습니다. 개인적으로 저는 실제 도메인 모델을 선호합니다.

이 기사에서는 Anemic과 비 Anemic 도메인 모델의 차이점에 대해 설명합니다.

글쎄, 엔티티와 비즈니스 객체는 대부분 거의 동일합니다. 예를 들어 제품 클래스가 있고 제품 ​​클래스의 기존 속성을 가져 와서 계산 한 다음 노출하는 속성을 노출하려는 경우가 있습니다. 그 속성을 만드는 논리는 클래스와 함께 유지된다는 용어로는 괜찮습니다.

이제 비즈니스 계층 클래스에 적합한 질문이 올 수 있습니다. 비즈니스 문제를 처리 할 논리가있는 비즈니스 계층 클래스를 선호합니다. 예를 들어 제품 예제에서 비즈니스 문제는 페이팔과 같은 타사 공급 업체를 사용하여 비용을 청구 할 수 있습니다.

기억해야 할 한 가지 중요한 사항은 엔터티는 항상 아이디를 가지지 만 비즈니스 객체는 아이디가없는 엔터티입니다. 예를 들어 제품은 실체이지만 돈은 정체성이 없습니다. 1000 개의 서로 다른 돈 사례는 동일합니다.