Правильный способ начать Behat функцию / историю
Я начинаю BDD и после некоторых чтений я обнаружил, что он хорошо сочетается с DDD.
Теперь у меня есть этот домен, где Institution иметь Places, которые добавляются к Institution от Assignee который является User назначен руководителем организации.
Я все еще не могу обернуть голову, как это должно быть, но эта функция звучит так: Как правопреемник учреждения, я должен иметь возможность добавлять места в организацию
Код, о котором я думаю (извините за подход с первым кодом), будет выглядеть так:
if ($institution->isAssignee($user)) {
$institution->addPlace(/* properties*/);
}
Теперь, как мне написать функцию и ее сценарии? Должен ли я оставить в качестве правопреемника расстаться и оставить? ИЛИ должно быть несколько сценариев? Как будет выглядеть сценарий?
РЕДАКТИРОВАТЬ:
Поэтому я оставил проверку прав доступа пользователя и запустил первую функцию, а затем спецификации реализации. Код можно найти Вот.
Разве эта функция не проста? Конечно, это суть того, что делает мой домен, но я даже не упомянул в своей функции случай, когда место с таким же местоположением не может быть добавлено, но я сделал это в InstitutionSpec?
Двигаясь вперед: если я хотел бы редактировать Place учреждения, что было бы лучше:
$place = $institution->getPlace($placeId);
$place->editWhatever(/***/);
ИЛИ ЖЕ
$institution->editWhateverInPlace($placeId, /** edits **/);
Решение
Проверка, что у пользователя есть разрешение на добавление места в Institution кажется чужим bounded context(BC) проблема вроде Authorisation, Эта проверка может быть сделано в Anticoruption layer в Application layer вне Institution aggregate запрашивая Authorisation BC создать Assignee от пользователя, который играет роль "assignee",
В этом до н.э. есть только Assigneeвозможно реализовано Value object которые имеют UserId и возможно name,
Постскриптум Ваш BDD тесты должны быть разделены на BC и кроме того Aggregate,
Другие решения
Я читаю твои сценарии, Я думаю, что вы смешиваете сценарии в одном в Не могу добавить место с тем же местоположением
Обычно при запуске большинство разработчиков думают о повторном использовании всех шагов. Вы просто скрыли, что должен показывать этот сценарий — заблокировать добавление нового места с такими же координатами. Просто первым шагом должно быть (на мой взгляд):
Given an institution named "Test institution" with places:
| name | coordination |
| Test Place | 54.222,24.333 |
Затем отшлифуйте свои сценарии таким образом, чтобы найти правильное наименование, показывающее проблемы.
Как вы спрашиваете: Isn't this feature to simple? — если каждый сценарий правильно разделен по функциональности — тогда НЕТ — вы разрабатываете свой код по поведению. Если это только то, что вам нужно, то ОК, но вы должны также подумать о граничных условиях функциональности — добавьте следующие сценарии.
О последней части, с местом редактирования — подумайте о SOLID.
Я слышу хороший пример этого: D
Что ты предпочитаешь:
- попал в клетку -> поймать льва -> схватить живот за челюсть -> положить пищу внутрь -> положить живот обратно -> оставить
ИЛИ ЖЕ
- пойти в клетку -> бросить еду льву -> уйти?
Первый вариант перерыва Закон Деметры это основа SOLID, когда вы пытаетесь схватить «желудок» учреждения.
Я думаю, в вашем контексте, второй вариант лучше.
detector