谷歌叙述_一种叙述性的软件设计方法

谷歌叙述

This article was originally published on my homepage — https://kislayverma.com/software-architecture/a-narrative-approach-to-software-design/

这篇文章最初发表在我的主页上— https://kislayverma.com/software-architecture/a-narrative-approach-to-software-design/

To me, the design stage is the most intellectually stimulating part of the software development cycle. After all, the design decides what the code will do, and how it will do it. The design process gives technical shape to what are till then only business requirements. We get to the deepest what’s and why’s at this stage — it is a lot of fun!

对我而言，设计阶段是软件开发周期中最能激发知识的部分。 毕竟，设计决定了代码将要执行的操作以及代码将如何执行。 设计过程使直到那时只有业务需求的技术成形。 在这个阶段，我们深入了解什么是什么，为什么这样做-这很有趣！

Here’s my rule of thumb about approaching software architecture — Approach designing a system/feature like you are writing an investigative story. That’s essentially what the design exercise is — we are poking around in the problem space/requirements to figure out how we might solve it. And like any good investigator, we ought not to make assumptions early on or jump back and forth between incidents. All we have is a burglary — deciding to shadow the sinister looking neighbour up front is probably not the best of course of action.

这是我接近软件体系结构的经验法则- 就像编写调查性故事一样，设计系统/功能 。 从本质上讲，这就是设计工作的本质-我们在问题空间/需求中四处寻找以找出解决方案。 而且，与任何优秀的调查员一样，我们不应在事件发生之前就做出假设或在事件之间来回跳动。 我们所拥有的只是一个入室盗窃-决定躲在前面险恶的邻居看来可能不是最好的选择。

I love crafting architecture narratives because they sit “above” any technical approaches and provides a framework for applying any of them. It also like it party because it has worked very well for “most” of the problems “I have worked on” (which are mostly application engineering problems using service-based architecture), and partly because even when it doesn’t provide actual technical design (e.g. in big data related problems), it helps me understand the problem domain deeply.

我喜欢设计体系结构的叙述，因为它们位于任何技术方法的“上方”，并为应用它们提供了框架。 它也喜欢它的聚会，因为它在“我处理过的”大部分“问题”(主要是使用基于服务的体系结构的应用程序工程问题)上都表现出色，部分原因是即使没有提供实际的技术支持设计(例如与大数据相关的问题)，它可以帮助我深入了解问题领域。

Start from a broad lay-of-the-land, then identify specific facts and occurrences, then progressively focus on each of them to see how they tick — all the while keeping the thread of overall technical story in hand. The process should feel very organic and evolutionary — a breakdown of high level business requirement into somewhat lower level technical constructs into technical components into the lowest level of implementation details and technology choices. It is a little bit like doing Bog Post Driven Development for engineering teams.

从广泛的领域开始，然后确定特定的事实和事件，然后逐步集中注意每个事实和事件，以查看它们的变化方式-同时始终牢牢掌握整个技术故事的脉络。 该过程应该感觉非常有机且具有发展性-将高级业务需求分解为较低级别的技术构造，再分解为技术组件，再分解到最低级别的实施细节和技术选择。 这有点像为工程团队进行沼泽后期驱动开发 。

You can slice this breakdown in many ways, but in most cases a few logical levels suffice.

您可以通过多种方式对这种细分进行细分，但在大多数情况下，只需几个逻辑级别即可。

高级设计 (High Level Design)

This fits our system or feature in the overall big picture and defines why we need it. It also assigns our system specific responsibilities which no other system can fulfil. This is where we think about whether we need this thing in our organization and who might be consume it.

这适合我们的系统或功能，并定义了我们为什么需要它。 它还分配了我们系统特定的职责，其他系统无法履行。 我们在这里考虑我们是否需要组织中的东西以及可能由谁来使用它。

组件级设计 (Components Level Design)

Now we look at our system itself and try to figure out what it is made up of. Any system of some complexity with be composed of multiple sub-parts and here we identify them, name them, and attribute behaviours to them. Every time a component is described, it feeds the narrative of the overall system by defining the unique role it plays in its functioning and how it works with the other components. This level forces decisions around domain boundaries and how different concepts of the system interact with each other.

现在，我们查看系统本身，并尝试找出它的组成。 任何复杂的系统都由多个子部分组成，在这里我们对其进行识别，命名以及将它们的行为归因于这些子部分。 每次描述一个组件时，它都会通过定义组件在其功能中扮演的独特角色以及如何与其他组件一起工作来提供整个系统的叙述。 此级别迫使围绕域边界的决策以及系统的不同概念如何相互影响。

低层设计 (Low Level Design)

Now we look inside each component and explain how it actually works on the inside. This is usually the point at which we will be forced to make some concrete choices about technology choices and other physical details like deployment and performance.

现在我们看一下每个组件的内部，并解释它实际上如何在内部工作。 通常这是我们被迫就技术选择和其他物理细节(如部署和性能)做出一些具体选择的时候。

Don’t critique the oversimplifies example taken above, but focus on the fractal like approach applies a different set of design principles at each level but in the same philosophical manner of composition and decomposition. Enterprise Design Architecture principles might apply at the highest level, Reactive design principles at the component level, and SOLID principles at the low level — but the entire exercise if about explaining the how the parts and the sum of the parts functions.

不要批评上面简单化的例子，而是要关注分形方法，在每个层次上应用不同的设计原则集，但以相同的哲学方式进行组合和分解。 企业设计体系结构原则可能适用于最高级别，响应式设计原则适用于组件级别，而SOLID原则适用于较低级别，但是如果要解释零件的组成部分以及零件总和的功能，则应进行整个练习。

Of course, not all design will need all of these level. Don’t fit them to this pattern forcibly. Build your own story — it can be a short one too!

当然，并非所有设计都需要所有这些级别。 不要强行让他们适应这种模式。 建立自己的故事-也可以是一个简短的故事！

为什么要撰写架构叙述 (Why write architecture narratives)

肠感检查 (Gut Feel Checks)

The narrative centric approach comes with gut-feeling checks around jarring changes in levels of abstraction. If your technical story feels like you suddenly skipped a few chapters and need to go back and check what happened, you have either missed laying out some important details or have jumped over them by making some assumptions. If you feel this is happening like going directly to implementation details, or talking about technologies that you might use, or naming service that you will build, it is usually a good idea to step back and focus on getting the plot line in the right order. What is it -> what does it look like -> what does it do -> how does it do it.

以叙事为中心的方法附带了围绕抽象级别的变化的直觉检查。 如果您的技术故事感觉像您突然跳过了几章而需要回过头来检查发生了什么，则说明您错过了一些重要的细节，或者通过做一些假设而跳过了这些细节。 如果您感觉到发生这种情况，例如直接转到实现细节，谈论您可能使用的技术或命名要构建的服务，通常最好退一步并集中精力按正确的顺序绘制图线。 它是什么->它是什么样的->它是做什么的->它是如何执行的。

A story that jumps all over the place is usually not very good (unless it’s a time travel story — in which case it is all right).

一个到处跳跃的故事通常不太好(除非是时空旅行的故事，在这种情况下就可以了)。

建立共同的愿景 (Build a shared vision)

Another advantage of explicitly building a story comes when you have to share it/convey it to others. If you are working with a team — sticking to a narrative breakdown allows the entire team to align with and contribute to the plot as it is being shaped. Not only does this put a lot more options on the table early, it will also set a shared vision around which all further decisions can be based. And once the design is ready and to be shared with managers or stakeholders or other engineers who might not yet understand the problem domain as you now do — you already have a story to sell! Not just the final ready artefact in the shape of implementable design, but also the process of how your team got there. This will help everyone understand the design better, it will also help them the problem structure and thus give better feedback.

明确构建故事的另一个优点是，您必须将其共享/传达给他人。 如果您与团队合作-坚持叙述性细分，则整个团队可以在情节塑造时与情节保持一致并做出贡献。 这不仅可以尽早提供更多选择，还可以树立一个共同的愿景，以此为基础制定所有进一步的决策。 一旦设计就绪，并可以与您现在不了解问题域的管理人员，利益相关者或其他工程师共享—您已经有故事可以出售了！ 不仅是可实施设计形式的最终成品，而且还包括团队如何实现目标的过程。 这将帮助每个人更好地理解设计，也将帮助他们解决问题的结构，从而提供更好的反馈。

A steady, systematic breakdown of the problem from high level requirements to low level implementation details demonstrates that you put in the necessary diligence. The documentation will also be more self-explanatory because the processing backing it is self-explanatory. If you are selling a large idea to management, this can be invaluable. Also when you have to explain why some seemingly trivial feature will take more than 3 hours to implement.

从高级需求到低层实施细节的系统的，系统的，稳定的细分表明您进行了必要的努力。 该文档也将更加不言自明，因为支持该文档的过程是不言自明的。 如果您要向管理层出售一个大创意，那么这将是无价之宝。 另外，当您必须解释为什么某些看似微不足道的功能要花3个多小时才能实现时。

尽可能推迟决定 (Postpone decisions as much as possible)

The last advantage of design-as-a-story is that you get to postpone decision. No good story start with lots of details. The best of them build characters over an extended period so that the characters have had to pass through many situation and evolve the version you actually fall in love with. Likewise we don’t want to start out by saying “recommendation engine will be built using Spark and Hadoop”. That can wait. Before we reach that point, we want to talk A LOT about what the recommendation engine is, who needs it, how it recommends, how it might change over time, who will build it etc etc. All of these things are important in making that final decision about exactly what we will build it with. We want to get know the persona of the engine before we pick his favourite weapon. The narrative approach is a good way to force that discipline on the design — concrete things are always decided as late as possible.

故事设计的最后一个优势是您可以推迟决策。 没有一个好故事始于许多细节。 他们中最好的人会在较长的时间内构建角色，以使角色不得不经历许多情况并发展您真正喜欢的版本。 同样，我们也不想说“将使用Spark和Hadoop构建推荐引擎”。 那可以等。 在达到这一点之前，我们想谈一谈推荐引擎是什么，谁需要它，它如何推荐，随着时间的推移它可能会如何变化，由谁来构建它等。关于我们将如何构建它的最终决定。 我们想在选择他最喜欢的武器之前了解引擎的角色。 叙事方法是将纪律强加于设计的好方法-具体事情总是要尽可能晚地决定。

买者自负 (Caveat Emptor)

With all that said, understand that everyone tells stories differently. This is just my way of doing things as I have learnt from experience and from others (Thanks Shamik, Abhinav, Sanjay, Apoorva, Govind) — it is certainly not the only way. Other people certainly approach it differently. There are data-first approaches, API-first approaches, UX-first approaches, Behaviour-driven-design and so on. You can use any of them to build great design — but remember that while people can always quibble with design, everyone like a good story :)

综上所述，请理解每个人讲述的故事都不同。 正如我从经验和其他人(感谢Shamik ， Abhinav ， Sanjay ， Apoorva ， Govind )中学到的，这只是我做事的方式-当然，这不是唯一的方式。 当然其他人也有不同的看法。 有数据优先的方法，API优先的方法，UX优先的方法，行为驱动的设计等等。 您可以使用它们中的任何一个来构建出色的设计-但请记住，尽管人们总是会with不休设计，但每个人都喜欢一个好故事:)

Read next — Highlight from “97 things every software architect should know”

接下来阅读— “每个软件架构师应该知道的97件事”中的重点

If you want to hear more about software design and architecture, sign up for my mailing list. New articles once a week!

如果您想了解有关软件设计和体系结构的更多信息，请注册我的邮件列表 。 每周一次新文章！

翻译自: https://medium.com/swlh/a-narrative-approach-to-software-design-c33f84fdf838

谷歌叙述