안녕하세요. 엔터프라이즈 응용 프로그램 아키텍처의 패턴을 방금 읽었습니다. 그들은 당신이 레이어에서 엔터프라이즈 애플리케이션을 수행해야한다고 말합니다. 그리고 하나의 레이어가 하나의 레이어 만 사용하도록되어 있지는 않습니다. 도메인 레이어는 DB 레이어를 사용할 수 있지만 그 반대는 불가능합니다. 그런 다음 도메인 객체를 만드는 DataMappers에 대한 장이 있습니다. 저기서 DB 레이어에서 DataMapper를 만들 수있는 이유가 무엇인지 궁금합니다. 도메인 레이어에서 객체를 만드는 이유는 하단에서 상단을 호출하지 않는다는 규칙을 따르지 않기 때문입니다. 그래서 내 질문은 DB 레이어에 실제로 도메인 객체가되어서는 안되며, DB 레이어에 도메인 레이어를 사용하지 않고 도메인 객체를 만드는 좋은 방법은 무엇입니까?응용 프로그램 계층화 및 DataMapper
나는 여기에서 문제가 있다고 생각합니다. 도메인 모델.
Data Mapper는 풍부한 도메인 모델에서만 필요합니다.이 경우 엔 엔티티 bean을 도메인 모델로 사용하지 말고 POJO를 사용하는 것이 가장 좋습니다.
이 방법을 사용하면 Data Mapper와 Domain Model 클래스가 DAO 및 엔티티로 구성된 지속성 레이어 위에 동일한 레이어에 있다고 주장합니다. 이 경우 데이터 매퍼는 데이터베이스에 대한 직접 작업을 수행하지 않습니다.
도메인 모델이 엔티티를 기반으로하는 경우이 또한 엔티티를 기반으로하며 데이터 매퍼도이 경우 DAO의 역할을 수행한다고 주장하므로 다시 (적어도 부분적으로) 동일한 층에있다.
최상의 솔루션은 무엇입니까? 책의 내용에 따르면 엔티티를 매우 단순한 경우에만 도메인 모델로 사용하는 것이 합리적이라고 할 수 있습니다. 복잡하지 않은 항목은 별도로 구성하십시오 (해당 책의 9 장의 도메인 모델 참조)
하나의 해결 방법 당신이 발견 한 문제는 도메인 객체와 데이터베이스 사이의 추상화 레이어를 사용하는 것입니다.
간단히 말해서 의존성 반전/주입.
데이터 공급자가 수행 할 수있는 모든 작업을 정의한 인터페이스를 정의한 다음 해당 인터페이스를 구현하는 구체적인 데이터 공급자를 작성하면 비즈니스 논리/도메인 계층에서 해당 작업과 통신합니다. 그렇게하면 데이터베이스에 묶여 있지 않습니다.
그런 다음 비즈니스 로직/데이터 개체와 인터페이스 (다시 사용하려는 경우) 사이에 또는 데이터 공급자와 관련된 세부 정보가 필요한 경우 데이터 액세스의 일부로 데이터 매퍼를 작성할 수 있습니다.
개인적으로 도메인 모델이 동작을 포함하지 않기 때문에 다른 레이어와 동일한 레이어라는 점에 개인적으로 동의하지 않습니다. 도메인 관련 엔터티/데이터 개체 일뿐입니다.
즉, 우리는 비즈니스 계층에만 특별하다는 결론을 내릴 수 없습니다. 일부 ORM 구성 요소를 사용하는 경우 자동이기 때문에 Domain-Model이 데이터베이스 계층에서 직접 사용됩니다. - 내부적으로 매핑.
"아래쪽으로"참조 할 수 있다고해서 항상 그렇다는 의미는 아닙니다. 당신은 올바른 길을 가고 있지만, 이해하지 못하는 채 맹목적으로 규칙과 원칙을 따르는 함정에 빠지지 마십시오. –