In my previous blog, I described what happened when Domain-Driven Design met Deadline Driven Design. Software design is a complicated activity. Pushing the deadline doesn’t work in most cases; cutting the software design will never work.
在我以前的博客中，我描述了域驱动设计遇到“截止日期驱动设计”时发生的情况。 软件设计是一项复杂的活动。 在大多数情况下，不能按时完成任务； 削减软件设计将永远无法进行。
没有现有的无设计软件，好坏 (Not existing no-design-software, it’s either Good or Bad)
Let’s first explain “the two-person job” mentioned in my previous blog. A basic question first.
让我们先解释一下“两人工作” 在我以前的博客中。 首先是一个基本问题。
Who designed your software?
谁设计了您的软件？
A, UX designer; B, Architect; C, BA; D, Developer;
A，UX设计师； B，建筑师； C，BA； D，开发商；
If you choose A, I would point your attention to Steve Jobs’ Quotes
如果您选择A，我将把注意力转向史蒂夫·乔布斯的名言
“Design is not just what it looks like and feels like. Design is how it works.”
“设计不仅是外观和感觉。 设计就是它的工作方式。”
If you choose B, I would argue that building software is not like constructing a building. It’s much more complex, you can’t copy and paste. Constructing a building usually can be broken down into well-defined duplication work. However when software is broken down into user stories or tasks, they are very different and need require expertise. Besides, some development teams don’t have an architect role at all.
如果选择B，我会认为构建软件不像构建建筑物。 它要复杂得多，您无法复制和粘贴。 建造建筑物通常可以分解为定义明确的复制工作。 但是，当将软件分解为用户故事或任务时，它们就大不相同，并且需要专业知识。 此外，有些开发团队根本没有架构师角色。
What happens when BA designs the software?
BA设计软件时会发生什么？
What I found in my personal experiences is that when BA is keen on giving suggestions or estimations in technical details, their contribution to software design and implementation quickly become chaotic or are treated as a conspiracy. They either overlook the technical risk or their technical knowledge is archaic.
从我的亲身经历中发现，当BA渴望在技术细节上给出建议或估算时，它们对软件设计和实现的贡献很快就会变得混乱或被视为阴谋。 他们要么忽视技术风险，要么他们的技术知识过时。
So is it the developer doing the design job? Yes and No!
开发人员是在做设计工作吗？ 是的，没有！
Alberto Brandolini, the creator of event storming said :
事件风暴的创造者Alberto Brandolini说：
“It’s not stakeholder knowledge but developers’ ignorance that gets deployed into production.“
“不是利益相关者的知识，而是开发人员对产品的无知被部署到生产中。”
Make no secret, I think a lot of existing software was built and “designed” by developers but unconsciously. After a developer accepts a user story, a continuous mind-flow is going through a developer’s mind to their hands and reaching to their keyboard and flowing into code repository days and nights even s/he usually doesn’t realize when and how they did the design.
不用说，我认为很多现有软件是开发人员在不知不觉中构建和“设计”的。 在开发人员接受用户故事后，不断的思维流经开发人员的思想到达他们的手，伸向他们的键盘，并日夜无休止地流入代码存储库，即使他/他通常不知道他们何时何地以及如何做的。设计。
However unfortunately even in a comfortable timeline, the software design work does not always end up in good hands ?
但是，不幸的是，即使是在适当的时间范围内，软件设计工作也不会总是能顺利完成吗？
Although developers usually are very intelligent types, they would get lost in developing the user stories like stuck in a maze when they don’t see and understand the whole picture of the system. They are more interested in new tools and cutting edge ways of doing things instead of absorbing and reflecting the business requirements.
尽管开发人员通常是非常聪明的类型，但是当他们看不到并了解系统的整体情况时，他们会迷失在陷入迷宫般的用户故事中。 他们对新工具和尖端的做事方式更感兴趣，而不是吸收和反映业务需求。
So my answer for software design: It’s a two person job.
所以我对软件设计的回答是：这是两个人的工作。
In my software development and consulting career, I do see a few shining moments, when BA was working together with developers to create very good software design activity and conversations. Sometimes BA was drawing their mind in a piece of paper with endangered UML language; sometimes BA was doing a role play to explain the business scenario, the developers pick those messages up and translate them into some workable software. Harmonious!
在我的软件开发和咨询生涯中，我确实看到了一些激动人心的时刻，当BA与开发人员一起创建非常好的软件设计活动和对话时。 有时，BA用一张濒临灭绝的UML语言写在纸上的想法； 有时BA扮演角色来解释业务场景，开发人员会挑选这些消息并将其转换为某些可行的软件。 和谐！
OK, so how do we know a software design is good or bad?
好的，那么我们如何知道软件设计的好坏呢？
财富(软件)设计有其独特之处，但所有不幸的设计都一样 (The fortune (software) designs have their own beauty, but all unfortunate designs all alike)
Amost all unfortunate software designs would come to a dominant architecture “ BIG Ball of Mud”.
几乎所有不幸的软件设计都将采用占主导地位的架构“ BIG Ball of Mud”。
There are many forces contributing to the “dominant architecture”, let’s focus on the complexity traits in those forces.
有许多因素促成“主导架构”，让我们关注这些因素中的复杂性特征。
“Complexity: One reason for a muddled architecture is that software often reflects the inherent complexity of the application domain. This is what Brooks called “essential complexity” [Brooks 1995]. In other words, the software is ugly because the problem is ugly, or at least not well understood. “
“复杂性：架构混乱的原因之一是软件通常反映了应用程序领域固有的复杂性。 这就是布鲁克斯所说的“基本复杂性” [Brooks 1995]。 换句话说，软件是丑陋的，因为问题是丑陋的，或者至少没有被很好地理解。 “
— described in http://www.laputan.org/mud/mud.html#Forces
—在http://www.laputan.org/mud/mud.html#Forces中进行了描述
A common misunderstanding is that adopting a microservice approach is going to escape the curse of Big Ball of Mud architecture.
一个普遍的误解是，采用微服务方法将逃避“泥浆大球”体系结构的诅咒。
MSA is Ops wised. It has advantageous in release and deployment.
MSA是Ops明智的选择。 它在发布和部署方面具有优势。
However, regarding software inherent complexity, microservice is a double-edged sword. On the one hand, microservice style could split the size of the complexity, and separate them into different code repositories and process. On the other hand, it added some extra complexity for MSA management. Let’s put the “technical complexity” for a while and focus on the “essential complexity” itself instead of technical complexity like MSA management stuff.
但是，就软件固有的复杂性而言，微服务是一把双刃剑。 一方面，微服务风格可以拆分复杂性的大小，并将它们分为不同的代码存储库和流程。 另一方面，它为MSA管理增加了一些额外的复杂性。 让我们将“技术复杂性”放一会儿，然后关注“基本复杂性”本身，而不是像MSA管理这样的技术复杂性。
Does MSA really help solve the “essential complexity” of your software? No!
MSA是否真的有助于解决软件的“基本复杂性”？ 没有！
MSA is brought out to solve fast delivery problems and operating scalability problems. Without a good domain model, recklessly adopting MSA, you are very likely to get a grid of small balls of mud instead of one big ball of mud.
MSA的推出是为了解决快速交付问题和运营可扩展性问题。 没有良好的领域模型，不顾后果地采用MSA，您很可能会得到一个由小泥球而不是一个大泥球组成的网格。
解决基本的复杂性(Tackle the essential complexity)
通过对话而不是文档来减少误会(Reduce misunderstanding by conversation instead of documentation)
The application domain is inherently complex, sometimes you can change it , sometimes you can’t. So a good strategy is to reduce or even eliminate the misunderstanding. Make sure you don’t create more complexity or misunderstanding to the inherent complex domain.
应用程序域本质上很复杂，有时您可以更改它，有时则不能更改。 因此，一个好的策略是减少甚至消除误解。 确保您不会对固有的复杂域造成更多的复杂性或误解。
A good conversation between domain experts and developers is the best way to eliminate the misunderstanding of the application.
领域专家和开发人员之间的良好交谈是消除对应用程序的误解的最佳方法。
One of the most important features of Event Storming and DDD is to enable communication between domain experts and the developers.
Event Storming和DDD的最重要功能之一是使领域专家与开发人员之间能够进行通信。
Look back why the waterfall design process does not work in software design, BA and developers work in different silos. BA came up with a very long Product Requirement Documentation and then passed it to the developer team. There is very little knowledge sharing and effective conversation regarding the software design and understanding.
回顾为什么瀑布式设计过程在软件设计中不起作用，BA和开发人员在不同的筒仓中工作。 BA提出了很长的产品需求文档，然后将其传递给开发人员团队。 关于软件设计和理解的知识共享和有效对话很少。
Individuals and interactions over comprehensive documentation
个人和全面文档之间的互动
避免谈论技术复杂性(Avoid talking about technical complexity)
A very common bad practice is to talk about technical details in DDD conversation. Remember DDD is technology agnostic.
一个非常常见的坏习惯是在DDD对话中谈论技术细节。 请记住，DDD与技术无关。
Compared to domain complexity, technical complexity is easy to manage and usually has some fixed pattern to follow. Please don’t want to waste the energy and mix the technical complexity into domain complexity. Besides, technical complexity is not a two person job. Bringing it up into the conversation would create confusion.
与领域复杂度相比，技术复杂度易于管理，并且通常遵循一些固定的模式。 请不要浪费能量，将技术复杂性混入领域复杂性中。 此外，技术复杂性不是两个人的工作。 将其带入对话会引起混乱。
Besides the conversation and domain model itself is highly evolving, so talking about the implementing details sometimes is just meaningless when the domain changes.
除了对话和领域模型本身在高度发展之外，因此，当领域发生变化时，谈论实现细节有时是毫无意义的。
Having said that, be ready to pacify people’s technical and implementation impulses during the DDD and event storming activity.
话虽如此，在DDD和事件风暴活动期间，请准备好安抚人们的技术和实施冲动。
形象化理解 (Visualize the understanding)
That’s a main feature of event storming. Spread all the events, commands, aggregates etc into the walls so that everybody can see it and change it. Visualization is powerful. No matter physically or virtually, it’s very helpful for people to understand the whole process and interlock between different parts.
这是事件风暴的主要特征。 将所有事件，命令，集合等传播到墙上，以便每个人都可以看到并更改它。 可视化功能强大。 无论从物理上还是虚拟上，这对人们了解整个过程并在不同部分之间互锁都是非常有帮助的。
Sometimes people could visualize it in different ways, eg drawing the diagram in a paper, or using UML tools, doing a role play to mock the business process is also a good idea.
有时人们可以以不同的方式对其进行可视化，例如在纸上绘制图表或使用UML工具，扮演角色来模拟业务流程也是一个好主意。
继续提问并重复理解 (Continue Questioning and Iterating the Understanding)
Rome wasn’t built in a day, so the application domain won’t be understood in one conversation.
罗马不是一天建成的，因此一次对话就不会理解应用程序领域。
It is not surprising that there are a lot of questions and misunderstandings between technical brains and business brains.
在技术头脑和商业头脑之间存在很多疑问和误解也就不足为奇了。
Don’t be frustrated if there are too many questions. That’s the whole meaning of DDD.
如果有太多问题，不要灰心。 这就是DDD的全部含义。
If nobody knows the problem, we should mark it for later or pick up the phone calling the end-user.
如果没人知道问题所在，我们应将其标记为以后使用，或者接听电话给最终用户。
On some occasions, developers don’t like to ask questions to the area they are not familiar with. What I usually do is to call the roll to ask questions and make sure everybody is on the same page.
在某些情况下，开发人员不喜欢向自己不熟悉的领域提问。 我通常要做的是打个招呼来提问，并确保每个人都在同一页面上。
Usually the application domain is very large and complex, so instead of doing it all for once, we should do it iteratively. Otherwise you won’t be able to deliver anything for a long time.
通常，应用程序域非常大且复杂，因此，我们不应反复进行所有操作，而应一次性进行所有操作。 否则，您将无法长时间交付任何东西。
In this article, I mainly talked about why DDD matters in the software design domain and some practises of doing it. In my next one, I would try to explain a swiss army knife of DDD event storming and how to make it more productive.
在本文中，我主要讨论了DDD为什么在软件设计领域很重要以及实现它的一些实践。 在下一个中，我将尝试解释DDD事件猛攻的瑞士军刀，以及如何提高生产率。
翻译自: https://medium.com/swlh/ddd-software-design-a-two-person-job-1f84af238e31
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
