ddd领域驱动设计_ddd域驱动的设计或截止日期驱动的设计

ddd领域驱动设计

When I asked my clients who know Domain Driven Design, less than 10% would nod their heads.

当我问那些了解域驱动设计的客户时，不到10％的人会点头。

However when I asked who experienced Deadline Driven Design, almost all would laugh and feel connected.

但是，当我问谁经历过“截止日期驱动设计”时，几乎所有人都会笑起来并感到联系。

将推车放在马前 (Put the cart before the horse)

Let me share an experience once I delivered DDD methodology to a customer.

将DDD方法交付给客户后，让我分享经验。

BA(Business Analysis) Mr. T is the one I coached for adopting event storming and DDD methodology to analyse the requirement and do the design afterwards in Lab1. After a short break, we met again for a second project Lab2.“

BA(业务分析)T先生是我所指导的，采用事件风暴和DDD方法分析需求并随后在Lab1中进行设计。 短暂休息后，我们再次见面，参加了第二个项目Lab2。”

We were standing in front of the following map which was completed by BA Mr. T. He looked quite puzzled with what he did.

我们正站在BA先生完成的以下地图的前面。他对所做的事情感到很困惑。

I said: “So this is the user story you sorted out? But where is the event storming”.

我说：“这就是您挑选出的用户故事吗？ 但是事件在哪里激增”。

Mr. T turned down a little bit his tone and avoided my eye contact as well, and said: “In Lab1, it seems to me that the output of event storming is just the user stories. So I thought it might be useful to come up with the user stories directly, so we can start the sprint more quickly. ”

T先生调低了语调，也避免了我的目光接触。他说：“在Lab1中，事件风暴的输出似乎只是用户的故事。 因此，我认为直接提出用户案例可能很有用，这样我们可以更快地开始冲刺。 ”

Put the cart before the horse

将推车放在马前

With a few seconds of silence and a little help of fresh air. I said that: “I agreed, user story is one of the visible outputs of event storming, However it’s much more than that and more important how do you know the user story is correctly reflecting the system’s mind.”

几秒钟的沉默和一点新鲜空气的帮助。 我说：“我同意，用户故事是事件风暴的可见输出之一，但是，不仅如此，而且更重要的是，您如何知道用户故事正确反映了系统的思想。 ”

Then I started a short lecture of values of event storming.

然后，我开始了关于事件风暴价值的简短讲座。

“First of all, we need to involve developers interactively. Event storming is a bridge connecting domain expertise and developer’s mind. With such an effective connection, the software can be built from mind flow from domain expertise’s brain to developer’s brain and go into the computer via developer’s hand.”

“首先，我们需要以交互方式让开发人员参与。 事件风暴是连接领域专业知识和开发人员思想的桥梁。 有了这种有效的联系，就可以构建从领域专家的大脑到开发人员的大脑并通过开发人员的手进入计算机的思维流程的软件。”

“Second, we need to identify different domains of our system, so we can prioritize them strategically. (eg seperate them as microservices or modules, or import 3rd party system to support.)”

“第二，我们需要确定系统的不同域，因此我们可以在战略上优先考虑它们。 (例如，将它们分离为微服务或模块，或导入第三方系统进行支持。)”

“You also want to understand the Aggregate output so that we can design the mindset of each unit of the system.”

“您还希望了解汇总输出，以便我们可以设计系统每个单元的思维方式。”

Mr. T smiled sneakily and said “I am OK with what you said, but we need the agreement of PO”. (PO is product owner)

T先生偷偷笑了笑，说：“我同意您的意思，但我们需要PO的同意”。 (PO是产品所有者)

After a replay the above conversation with PO who is the real boss to push the deadline.

重新播放以上与PO的对话后，PO是真正的老板，可以推动截止日期。

The words I added to the PO is that “I understand we need to meet the deadline. However, sharpening the knife doesn’t delay chopping wood. Event Storming is invented to do business process analysis in fast paced.”

我在采购订单中添加的文字是：“我了解我们需要在截止日期之前完成。 但是，磨刀不会延迟砍柴。 发明Event Storming是为了快速进行业务流程分析。”

With one day intensive activities, developers, BA and coach finally got the partial of the process’s event storming look like this.

经过一天的密集活动，开发人员，BA和教练最终得到了该过程中的一部分事件风暴，像这样。

Part of the Event Storming map

事件暴风雨地图的一部分

Standing in front of this wall, I saw Mr. T relieved.

站在这堵墙的前面，我看到T先生松了一口气。

I asked “What’s the difference regarding the user stories before and after?”

我问“前后的用户故事有什么区别？”

Mr. T said: “Firstly, we identified a lot of hidden user stories. eg: ’Contract Body Attachment‘ Aggregate’, this was missed when I tried to sort out all the scenarios in my head.“

T先生说：“首先，我们发现了很多隐藏的用户故事。 例如：“合同正文附件”汇总”，当我尝试整理脑海中的所有情况时，这是缺少的。”

I said: “Why did you miss that bit, it seems quite important.”

我说：“您为什么想念那一点，这似乎很重要。”

Mr. T said: “Yep, Strange! When I want to grasp all the user stories from my mind, it seems like I only see the forest, but I can’t see the woods. So I can’t identify a lot of details. But when we start event storming, I feel like I step into each path of the forest and go through it, the important objects are getting clear.”

T先生说：“是的，很奇怪！ 当我想从脑海中掌握所有用户故事时，似乎只看到森林，却看不到森林。 因此，我无法确定很多细节。 但是，当我们开始事件风暴时，我觉得我走进森林的每条路径并经过它，重要的物体越来越清晰了。”

I said: “Right, event storming helps you expand your mind into these unlimited walls and make them visible to everyone. It does not only help you create clearance on the business process but also help all the developers to see all the details and understand the mindset of the whole process.”

我说：“对，事件风暴可以帮助您将思维扩展到这些无限的墙中，并使所有人都能看到它们。 它不仅帮助您在业务流程上建立了清晰的关系，而且还帮助所有开发人员查看了所有细节并了解了整个流程的思维方式。”

I added: “What about the communication. Is that helpful?”

我补充说：“那沟通呢。 这有帮助吗？”

Mr. T nodded his head, and said: “Yep, it solves some of my puzzles in the beginning, I know what stucks me now and then I picked up the phone and asked the end-user in detail and that’s really helpful.”

T先生点了点头，说道：“是的，它从一开始就解决了我的一些难题，我知道是什么困扰了我，然后我拿起电话并详细询问了最终用户，这真的很有帮助。”

I said: “You also received tons of questions from the developer team, right? They won’t be able to ask those questions until they see all the details you spread them into the wall. If they don’t ask your those questions in advance, they would ask you in the late time of the sprint. Otherwise they are likely to stuck or hide the problem and you would see huge numbers of WIP items in your kanban. That’s a common pitfall when using scrum kanban, Too many WIP. But we need to ask why, shouldn’t we?”

我说：“您还收到了开发人员的大量问题，对吗？ 在看到您将它们传播到墙上的所有详细信息之前，他们将无法提出这些问题。 如果他们不事先询问您这些问题，他们会在冲刺的后期询问您。 否则，它们可能会卡住或隐藏问题，并且您会在看板中看到大量WIP项目。 使用Scrum看板( 太多WIP)时，这是一个常见的陷阱。 但是我们需要问为什么，不是吗？”

Mr. T smiled and he seemed quite familiar with the scenario that I described.

T先生笑了笑，他似乎对我描述的场景非常熟悉。

“Now you know how many domains we should separate, which domain we should work on in sprint 1 instead of putting a lot of scattered user stories into one sprint, right?

“现在您知道我们应该分隔多少个域，在sprint 1中应该处理哪个域，而不是将许多分散的用户故事放入一个sprint中，对吧？

We even figured out how many microservices we are going to have for the system and how they are going to interact, isn’t it helpful?”

我们甚至已经弄清了系统将要拥有多少个微服务以及它们将如何交互，这是否有帮助？”

…

…

磨刀不延迟砍木头 (Sharpen the knife doesn’t delay chopping wood)

Let’s end our story here, Event storming is really a simple but powerful tool to hold the two person job conversation.

让我们在这里结束我们的故事，事件风暴实际上是进行两人工作对话的简单但功能强大的工具。

So what is the two person job? Let me expand it in my next blog. I am going to describe how event storming saves the software design domain.

那么，两个人的工作是什么？ 让我在下一个博客中对其进行扩展。 我将描述事件风暴如何节省软件设计领域。

翻译自: https://medium.com/swlh/ddd-domain-driven-design-or-deadline-driven-design-6d7a2bbf34ff

ddd领域驱动设计