提示4-2:将解决方案方法描述为表格!
提示4-2:将解决方案方法描述为表格! #solution-strategy #table #concept #scenario #quality-goal #lean #essential 将解决方案方法描述为包含以下列的表格: 质量目标:最高级别目标是什么?场景:这个质量目标的详细场景是什么?解决方案方法:系统如何处理这种情况?朝着这个方向采取了哪些策略、方法或决定?链接到详细信息:此解决方案的详细信息在哪里描述?这个链接要么指向一个具体的构建块,(实施方法) ...
提示4-5:让解决方案策略迭代/增量增长!
提示4-5:让解决方案策略迭代/增量增长! #solution-strategy #lean 解决方案策略可能会在开发过程中演变:不要试图预先决定一切,而是更好地迭代/增量构建您的系统。 每当您证明一个想法、方法或概念有用时,您就可以添加适当的文档。 ...
提示5-15:沿目录和文件结构将源代码映射与构建块对齐!
提示5-15:沿目录和文件结构将源代码映射与构建块对齐! #building-block #source-code #mapping #lean 如果您(源代码)文件系统中的目录直接对应于您的构建块,您将获得源代码与构建块之间最简单的映射。 考虑以下示例:在其左侧,您可以找到构建块的层次结构(a,b,c细化为 level 1 ,b2和c1,细化为2级)。在右侧,您会看到相应文件系统的快照,其中包含(高级)目录a、b和c以及相应的子目录。 ...
提示6-2:只记录几个运行时场景!
提示6-2:只记录几个运行时场景! #scenario #runtime-view #lean #essential #runtime-scenario 创建场景非常耗时由于创建和维护运行时场景非常耗时,请关注: 重要的,真正具体、复杂、有风险或其他有趣的。有助于设计构建块或挑战相应设计决策的场景。主要使用场景来识别和讨论构建块行为,并仅保留几个场景作为文档。 在文档中只保留几个场景仅记录以下场景: 对于了解系统内的整体处理至关重要,即最重要的功能、特性或用例, 对 ...
提示6-3:记录“示意图”(而不是详细)场景!
提示6-3:记录“示意图”(而不是详细)场景! #scenario #runtime-view #lean #runtime-scenario 对特定过程、活动或功能的“示意图”概述通常足以理解系统不同构建块之间的交互。 特别是开发人员倾向于在源代码中寻找细节,因此他们不需要非常详细的图表。 在“原理图”场景中,您指的是更高层次的抽象,来自更高层次(例如 level 1 )的构建块视图。 在以下场景中,只有相应构建块视图的 level 1 构建块进行交互。 示例的构建 ...
提示6-9:使用文本符号来描述运行时场景!
提示6-9:使用文本符号来描述运行时场景! #runtime-view #scenario #lean 我们对开发团队的建议:使用PlantUML描述或指定运行时场景。它有一个用于序列和活动图的轻量文本语法(DSL)-易于理解,是讨论和可视化活动和过程的精益选项。 123456789101112131415161718192021222324252627282930313233@startumlskinparam componentStyle uml2actor Admi ...
提示7-10:将硬件决策留给硬件专家!
提示7-10:将硬件决策留给硬件专家! #deployment-view #lean 如果您主要关注软件架构,并且您的组织中有不同的人关心硬件和技术基础设施,请将此基础设施的文档留给他们。 仅在软件架构文档中包含此类信息,这是理解相关架构决策所必需的。 我(Gernot)在几个组织工作,这些组织将系统运营承包给了(外部)数据中心。这些数据中心有自己的文档方法和工具,通常不想与我们软件人员共享他们的许多文档……(我不喜欢这种组织分离,因为我更喜欢像集成团队这样的开发操作,但 ...
提示7-7:使用表格记录软件/硬件映射!!
提示7-7:使用表格记录软件/硬件映射!! #deployment-view #lean 作为带有部署图的图形映射的(简单)替代方案(见提示7-6(部署图)),您可以使用表格来记录或指定软件在硬件上的部署。 服务器 神器 评论 OneServer 一个docker容器,至少需要Docker V 12.1 域名服务 由Gradle构建脚本自动部署 其他服务器 戴尔(c)服务器,四核i7 CPU,64GB RAM,运行RH Ente ...
提示8-1:解释概念!
提示8-1:解释概念! #concept #lean #essential 概念通常包含最基本的解决方案方法。理解这些概念是理解架构的先决条件。 概念构成了架构概念完整性(一致性、同质性)的基础。 它们为反复出现的问题提供了陈规定型的解决方案。 您通常可以通过解释概念来节省大量文档工作,而不是专注于构建块细节。 ...
提示8-10:使用arc42的集合作为概念的清单!
提示8-10:使用arc42的集合作为概念的清单! #concept #lean 类别 话题 解释 领域概念 即领域模型、业务数据模型 用户体验概念(UX) 用户界面 人体工程学 国际化(i18n) 如何使系统可用于国际环境、翻译、屏幕布局、措辞等 安全和安保概念 安全 即如何实现保密、无信誉和其他目标。 安全 安全关键型系统是指那些故障或故障可能导致死亡或受伤或严重经济损失的系统 架构和设计模式 系统 ...