Разработка домена домена - домен или безопасность

Question

Я создаю приложение с использованием DDD. Это приложение для оценки сотрудников. В рамках уровня домена у меня есть оценочный документ. Что можно сделать с этим документом, зависит от роли, которую пользователь играет в отношении документа оценки, но также зависит от статуса документа.

Являются ли эти концепции домена или это проблема перекрестной резки - безопасность ???

Как вы передаете пользовательскому интерфейсу, какие действия допустимы ???

Answer 1

Это несколько сложный вопрос. Проблема может заключаться в том, что ваши бизнес-эксперты уже уладили концепцию Appraisal Document, которая является реликтом предшественников компьютеров или старых приложений, к которым они уже привыкли. Тем не менее, Appraisal Document - это просто инструмент эры до компьютера, который люди используют для обработки фактической оценки, но это, скорее всего, не концепция, которая на самом деле происходит в реальном бизнесе оценок. Например, если вы заменили сообщение Appraisal Document связью «рот в рот», процесс оценки, скорее всего, изменился бы очень мало, и эти проблемы безопасности на Appraisal Document переведут на такие политики, как «супервайзер не должен говорить об оценке сотрудника с другими сотрудниками »или« всегда получают второе мнение ».

(Иногда я вижу связанную с этим проблему в области медицинских медицинских записей, где большинство врачей уже привыкли к программному обеспечению, так что они, похоже, путают электронный HR - который что-то документирует - с фактическим лечением/диагнозом - - для документирования.)

Чтобы решить эту проблему, ваши бизнес-эксперты должны освободиться от концепции Appraisal Document и сосредоточиться на процессе оценки. Как вы уже сказали, есть определенные роли, которые люди играют во время оценки, например, Супервизор, Участник, Сотрудник, Рефери и статус документа, фактически ссылаются на концепцию в процессе (принцип второго взгляда или аналогичный). Эти роли и процесс должны быть четко и точно смоделированы в вашей оценке BC, возможно, с участием саги/продолжительного процесса. Затем становится ясно, что те проблемы безопасности, которые ограничивают доступ Appraisal Document, фактически являются ограничениями в пределах фактического домена и сильно связаны с соответствующими ролями и состоянием процесса в вашем домене.

Применение интерфейса вашей оценке нашей эры может предложить услуги для приложения, которое использует соответствующие роли, например, gradeEmployee(String supervisorId, String employeeId, Integer grade) или viewAppraisal(String viewingSuperVisorId, String appraisalId) или involveReferee(...). В этом случае интерфейс приложения Appraisal BC должен гарантировать, что действия действительно разрешены; поскольку он будет вызывать бизнес-методы модели домена, например. AppRaisalDomainService.mayPublishReport(supervisor, appraisal)

Все, что осталось сделать в вашем приложении, - это сопоставление пользователей вашей заявки с соответствующими supervisorId/employeeId. Например, вы можете взглянуть на ограниченный контекст «Collaboration» Vaughn Vernon в репозитории [IDDD_Samples] [1], где у людей есть такие роли, как Moderator, Author и т. Д., А также то, как контекст сотрудничества используется из других связанных BCS.

Наконец, в вашем пользовательском интерфейсе вы можете представить текущее состояние процесса оценки своим пользователям. Страница «детали» одной оценки автоматически станет «оценочным документом», к которому привыкли люди. Вы даже можете дать право на просмотр своего пользовательского интерфейса «Документом оценки» или аналогичным, чтобы удовлетворить ваших пользователей, и если они распечатывают это представление, они фактически хранят такой документ в своих руках.Однако в базовом приложении доступ не ограничивается «Документом оценки», а скорее основным процессом оценки, а ограничения доступа - это концепция домена.