나는이 같은 내 솔루션 탐색기에 다양한 층 (클래스 라이브러리 프로젝트)를 분리 한 :비즈니스 계층에서 DDD 패턴을 시작으로
나는 저장소 계층에서 PetaPoco을 추가 PetaPoco 마이크로 ORM 및 someone suggested me을 사용하고 싶습니다. 필자는 PetaPoco를 저장소 프로젝트에 추가하고 데이터베이스에서 모델을 생성했습니다. 이제 자동으로 생성 된 POCO가 저장소에 있습니다.
내가 따르지 않는 것은 DDD를 구현하려는 경우 모델의 모든 POCO, 즉 비즈니스 계층을 원한다는 것입니다.
WebUI 레이어에서 사용자 로깅을위한 WebForm을 추가했습니다. 이제 DDD를 사용할 때 Model에서 인터페이스가 필요합니까? 유효성 검사 로그인 방법은 어디에서 작성해야합니까?
도메인 기반 디자인에 관한 Eric Evans의 책을 다시 읽으시기 바랍니다. 너도 봐야지. 책 뒤의 에반스의 비디오. DDD는 리포지토리, 데이터베이스, 어셈블리 또는 사용자 로그인과 관련이 없습니다.
DDD가 실제로 찾고있는 것이 아닐 가능성도 있습니다. 일부 엔티티/앱 - 서비스 상단에있는 UI를 사용하여 계층 적 접근 방식을 찾고있는 것처럼 보입니다. 당신이 만들고있는 것에 따라 이것은 실제로 당신이 필요로하는 모든 것이 될 것입니다.
PetaPoco를 사용하고 "orm"이 db에서 "models"를 생성하는 경우 다른 프로젝트에서 이들을 구분하는 것이 중요하지 않습니다. 모델이 orm에 의해 생성된다는 사실 (그리고 미래에 재 생성 될 필요가 있다는 사실)은 orm과 상당히 결합되어 별개의 어셈블리에서 그들을 움직이면 아무것도 얻지 못합니다.
ValidateLogin 질문에 대답하려면 모든 인증 관련 코드를 다른 레이어와 직각 (수직) 인 인프라 계층으로 이동하는 것이 좋습니다. 앱 사용자는 '엔티티'일 필요는 없습니다. auth를 처리하는 모델 계층에 app-service가있을 수도 있지만 일반적으로 승인은 비즈니스 관련 문제가 아니라 인프라 관련 문제임을 알게되었습니다.
결국 나는 함정과 그런 건축물의 장점에 익숙해지고 건물에 적합한지를 결정할 것을 제안합니다. 반면에 DDD는 구축하기가 저렴하지 않으며 (Evan이 말했듯이) 처음 몇 번 제대로 실행하지 못할 수도 있다는 사실을 알고 있어야합니다.
감사합니다. ORM을 무시하고 LINQ를 사용하면 어떨까요? 로그인을위한 인터페이스를 만들어야합니까? – RKh
정말 중요하지 않습니다. 먼저 로그인 프로세스가 비즈니스 프로세스의 일부인지 여부를 인프라 측면에서만 고려해야하는지 결정해야합니다. 비즈니스 프로세스의 일부인 경우 사용자 엔티티와 유효성 검증/인증을 수행 할 수있는 앱 서비스를 갖게됩니다. 인프라 관련 문제라면 인프라 구성 요소가 필요합니다. –