开始 Behat 功能/故事的正确方式答案

【问题标题】：The right way of starting Behat feature/story开始 Behat 功能/故事的正确方式
【发布时间】：2017-04-07 10:02:58
【问题描述】：

我正在启动 BDD，经过一些阅读后我发现它与 DDD 配合得很好。

现在我有了这个域，其中一个Institution 有一个Places，它们被Assignee 添加到Institution，这是一个分配为组织经理的User。

我仍然无法理解它应该如何，但功能听起来像：作为机构的受让人，我必须能够为组织添加位置

我正在考虑的代码（对不起，代码优先的方法）如下所示：

if ($institution->isAssignee($user)) {
    $institution->addPlace(/* properties*/);
}

现在我应该如何编写功能及其场景？我应该离开 作为受让人 部分并离开它吗？还是应该有多种情况？场景会是什么样子？

编辑：

所以我暂时离开了用户权限检查并开始了第一个功能，然后是实现规范。代码可以在here 找到。

这个功能是不是很简单？当然这是我的域的核心功能，但我什至没有提到我的功能中无法添加相同位置的地方的情况，但我已经在InstitutionSpec中做到了这一点？

前进：如果我想编辑机构的Place，有什么更好的方法：

$place = $institution->getPlace($placeId);
$place->editWhatever(/***/);

或

$institution->editWhateverInPlace($placeId, /** edits **/);

【问题讨论】：

标签： php domain-driven-design bdd behat

【解决方案1】：

检查用户是否有权向Institution 添加地点似乎是另一个bounded context(BC) 问题，如Authorisation。通过查询Authorisation BC 以从具有"assignee" 角色的用户创建Assignee，可以在Application layer 之外的Application layer 中完成此检查。

在这个 BC 中只有一个 Assignee，可能实现的广告 Value object 具有 UserId 和可能的 name。

附：你的BDD 测试应该被BC 和Aggregate 分开。

【讨论】：

确定用户是否是给定机构的受让人可能不像角色检查那么容易。我通常都支持 Identity & Access BC，但这里的支持上下文需要引入一组额外的抽象，例如在特定上下文或特定目标中发挥作用。直接在需要它的 BC 中对关联进行建模可能更容易。

【解决方案2】：

我看了你的scenarios，我认为你在Can't add place with same location中混合了一个场景

通常，大多数开发人员在开始时都会考虑重用所有步骤。您只是隐藏了这个场景应该显示的内容 - 阻止添加具有相同坐标的新位置。第一步应该是（在我看来）：

Given an institution named "Test institution" with places:
| name       | coordination  |
| Test Place | 54.222,24.333 |

然后像这样完善你的场景，帮助你找到更好的命名方式，显示问题。

正如您所问的：Isn't this feature to simple? - 如果每个场景都按功能正确拆分 - 那么不 - 您是按行为设计代码的。如果这只是您需要的，那么可以，但您还应该考虑功能的边界条件 - 添加下一个场景。

关于最后一部分，带有编辑位置 - 想想 SOLID。我听到了很好的例子：D

你喜欢什么：

到笼子里-> 抓狮子-> 用下巴抓肚子-> 把食物放进去-> 把肚子放回去-> 离开

或

去笼子 -> 把食物扔给狮子 -> 离开？

第一个选项 break Law of Demeter 是 SOLID 的基础，因为您试图抓住机构的“胃”。

我认为，在您的上下文中，第二种选择更好。

【讨论】：