问题描述
我喜欢中间出发展是与DDD实现。发展是由域，应用程序的最坚实的部分原因。我们不依赖于基础设施建设，坚持和演示。听起来不错。但它没有商业价值。
I like the middle-out development that is achieved with DDD. Development is driven by domain, the most solid part of application. We don't depend on infrastructure, persistence and presentation. That sounds good. But it has no business value.
下面谈到业务为重点的BDD与外而内的发展。我们没有前期域设计（选择实体，值对象，聚合）。我们以用户的故事，写一些场景和实现它们一个接一个。我们开始从应用程序的最多变一部分发展 - 从演示。我讨厌写作脆弱的验收测试。 ？你
Here comes business-focused BDD with outside-in development. We have no upfront domain design (choosing entities, value objects, aggregates). We take user story, write some scenarios and implement them one-by-one. We start development from most changeable part of application - from presentation. I hate writing fragile acceptance tests. Do you?
因此，如果有人在这里有关于BDD风格应用DDD的成功案例，请大家分享一些我：）
So, if someone here have successful stories about applying DDD in BDD style, please share some with me :)
- 请你写演讲那些脆弱的测试？
- 你有创造实现域用户故事的一部分之前一些设计前期？或者你对DDD模式重构实施后的故事？
任何帮助将不胜感激。谢谢！
Any help will be appreciated. Thanks!
推荐答案
我提供单北和我（请原谅兔子在车灯看，这是我的第一部影片）是由Eric Evans的关于BDD和DDD的一个同事采访了
I offer Dan North and myself (please excuse the rabbit in the headlights look, it was my first video) being interviewed by one of Eric Evans' colleagues on BDD and DDD.
您也可以拥有第一章草案的段先睹为快从BDD本书我写（希望与丹太）：
Also you can have a sneak preview of a segment of the draft first chapter from a BDD book I'm writing (hopefully with Dan too):
作为另一个效果，讨论的方案没有任何技术的话，在商业语言，允许开发人员回暖该语言。然后，他们进行了语言翻译成自己的代码库，实现业务域的元素命名的班级，这些元素的功能命名的方法和属性和变量自己现实生活的属性和子元素的名字命名的。
这在代码中使用的业务术语，被称为的通用语言的埃里克·埃文斯的书，领域驱动设计。埃里克认为，当开发人员开始在符合企业利益相关者术语的语言代码，谈话变成液体，而无需开发人员（或分析师作为代理），从技术细节到域的概念转换来回。该代码变得更容易阅读和新人理解。每个对象的系统中的值变得更明显，以及通过其提供其值返回给用户，使得用户可以提供的商业价值的路径。
This use of business terminology in code is referred to as the ubiquitous language in Eric Evans' book, "Domain Driven Design". Eric suggests that when developers start to code in a language which matches business stakeholders' terminology, conversations become fluid, without the need for developers (or analysts as a proxy) to translate back and forth from technical details to domain concepts. The code becomes more readable and easier for newcomers to understand. The value of each object in the system becomes more obvious, as well as the path by which it provides its value back to the user so that the user could provide value to the business.
JBehave推出一些新的东西。不仅是使用业务领域的语言的开发人员;他们现在正在使用该业务理解为描述软件术语的语言。相反，喜欢的话的测试的验收测试的行为的安排的断言的，的红色条的和的绿条的，开发商都在谈论的例子的场景的上下文的，的事件的的结果的和的行为的
JBehave introduced something new. Not only were the developers using business domain language; they were now using a language that the business understood to describe software terminology. Instead of words like test, acceptance test, act, arrange, assert, red bar and green bar, developers were talking about examples, scenarios, contexts, events, outcomes and behaviour.
JBehave和BDD，引进了一个无处不在的语言进行软件开发本身。
JBehave, and BDD, had introduced a ubiquitous language for software development itself.
希望这表明，BDD和DDD工作很好地结合在一起确实如此。所有反馈的欢迎，除了在我的穿着感。
Hope this shows that BDD and DDD work very well together indeed. All feedback welcome, except on my dress sense.
编辑：你说得对，域名是非常稳固。这就是为什么我们专注于像演示和基础设施更加危险的东西，说说我们的使用场景领域的理解。我们不能在我们的领域的理解得到的反馈，直到我们有一些得到反馈的与的 - 但它并不能阻止我们寻求反正理解
You're right, the domain is pretty solid. That's why we focus on the more risky stuff like presentation and infrastructure, and talk about our understanding of the domain using scenarios. We can't get feedback on our understanding of the domain until we have something to get feedback with - but it doesn't stop us seeking the understanding anyway.
这篇关于是否有可能使用DDD和BDD在一起吗？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！