도메인 드리븐 디자인 기술을 따르는 시스템을 개발하고 있습니다. 저의 목표는 직원 클럭을 캡처하고 클럭 아웃하는 것입니다. 한 가지 요구 사항은 주어진 시간 동안 동일한 직원에 대해 두 개의 연속적인 클럭을 허용 할 수 없다는 것입니다. 내 질문은이 규칙이 더 잘 어울리는 곳이며, 하나의 개체와 관련이 없지만 도메인 엔터티 위에있는 일종의 프로세스의 규칙으로 간주됩니다. 조언?도메인 기반 디자인의 입력 유효성 검사 일반 규칙을위한 장소는 무엇입니까?
질문에서 "일반 규칙"이란 단어가 부족한 요구 사항의 표시입니다.
질문에 대답 : "시스템에서 허용 할 수없는"것은 무엇입니까? - 사례를 기록해야합니까? 데이터 저장을 거부 하시겠습니까? 직원의 관리자에게 보고서를 보냅니 까?
도메인 모델은 모델링하는 도메인의 측면에 따라 크게 달라집니다.
대답을 통해보다 명확한 모델을 얻을 수 있으며 질문은 너무 주관적이어서는 안됩니다.
요구 사항에 따라, 그 수 :
employee의 행동;door의 행동;CorporateSecurity 서비스 동작; 편집 : 입력 할 수있는 데이터의 문제인 경우 입력 유효성 검사입니다. in Martin Fowler's bliki - 객체가 validate() 일 수 있고 유효성 검사 오류 컬렉션을 반환 할 수있는 좋은 접근 방법이 있습니다.
'시스템이 허용 할 수 없음'이란 말은 응용 프로그램이 그러한 종업원 시간을 버리고, 다른 방식으로 버려야하며, 지속될 수없고 사용자에게이 상황을 통보해야한다는 것을 의미합니다. –
내 대답을 업데이트했습니다. –
훌륭한 기사입니다.이 경우에는 내 길로 보입니다. –
이 문제를 처리하는 도메인 서비스를 가질 수 있습니다. 응용 프로그램 계층에서 해당 날의 모든 시계 기능을 가져 와서 도메인 서비스에 제공하도록 할 수 있습니다. 또는 IRepository가 도메인 계층에있는 경우 도메인 서비스에서 시계 기능을 요청할 수 있습니다.
이 '규칙'이 도메인 내의 실제 불변량이라고 가정하면 도메인 모델 내에서 시계 정보를 유지해야합니다. 결국 그것은 당신이 붙잡 으려고하는 행동처럼 들립니다.
데이터베이스가 도메인 모델의 디자인에 영향을주지 않도록주의하십시오. CRUD (작성, 읽기, 업데이트 및 삭제) 접근법을 적용하는지 또는 실제 도메인을 모델링하려고하는지 여부를 신중하게 고려하는 것이 좋습니다. 나중에 도메인을보다 효과적으로 모델링하는 데 도움이되는 다양한 제한된 컨텍스트를 발견 할 시간이 필요하다면.
도움이 될만한 게시물이 있습니다. 도움이 될만한 용어에 대한 정의가 있습니다. Aggregate Root – How to Build One for CQRS and Event Sourcing.
귀하의 게시물을 강 조하십시오. 필자의 경우 클럭 정보를 클라이언트에 넣고 싶지 않습니다. 그래서 시계 인스턴스가 매우 불안정하고 불과 몇 초 만에 존재합니다. 먼저 하나의 Clock을 만들 수 있는지 확인해야합니다. 그럴 경우 Write 명령을 만들어서 중간에 실행하십시오. 그런 다음에 Clock 인스턴스를 더 이상 instersted하지 마십시오. –
왜 단일 엔티티에 속하지 않습니까? 지금까지 도메인 모델은 무엇입니까? – guillaume31
@ guillaume31,이 인스턴스는 매우 휘발성이 있습니다. 일단 시스템이 Clock을 받아 들여 저장하면 completly 처리하고 싶습니다. 더 이상 메모리에 저장하지 않으려 고합니다. 왜 그 로직을 넣어야합니까? 사실 나는이 생존주기에 대해 생각하고 있었는데, 이것은 브라이브 (brebe)였습니다. 몇 초가 걸렸습니다. 인스턴스 나 일종의 쓰기 명령이 필요한지 궁금합니다.DDD 세계에서 그런 시나리오에 어떤 패턴이 있습니까? –
나는 당신을 얻지 않는다. 거래의 간결성이 "너무 가깝지 않은 클록 킹 금지"비즈니스 규칙에 영향을 미치는 이유는 무엇입니까? 데이터베이스에 마지막 클럭 인 시간을 저장할 수 없습니까? – guillaume31