如何分别确定架构和设计的抽象和范围？

Question

我正处于我的项目的架构阶段。我面临的挑战是，目前我无法保持一定程度的抽象。我经常悄悄进入我们通常作为设计的一部分来处理的领域。

我不知道该在哪里停止思考和阐述...因此，我最终阐述了该解决方案的非常详细的细节，这些细节将直接供程序员使用。在这个过程中，我失去了大局(视野)和专门致力于建筑目的的时间。

有没有什么方法/方法论/方法可以用来限制我自己在架构的范围内，当我在解决它的时候，同样的，当我在设计阶段的时候？

Answer 1

退后一步--您正处于架构阶段，那么此阶段需要生成哪些可交付成果？你知道你的项目中需要交付的涉众是谁吗？-他们需要/期望什么？我想指出的一点是，如果你没有清楚地确定你需要做什么，它就不会完成(无论你使用什么方法)。

限制/让您自己保持在目标上

一个好的架构将经历3个层次，这些是方法的良好基础：

• 高级方向:做任何事情来验证(并能够证明)给定的方向。我们应该建立什么样的系统？供办公室员工使用的桌面系统或可供远程用户随时随地使用的桌面系统在country-side?
• Logical选项中:完全远离实现细节，而是专注于确定您将需要的主要组件。我们需要存储数据，我们需要根据现有的外部服务对用户进行身份验证，我们需要提供一个UI。
• Physical options:这是您详细说明要使用的内容的地方。回到IT的比喻:我们是在使用实体映射框架，还是滚动我们自己的框架，还是重新使用预先构建的内部框架？

对于所有这些，您应该能够找到支持您的方法的参考架构或某种“现有技术”。

将输入到这3个步骤中可能是相当重要的，并且应该包括：

• 上下文(解决方案需要在其中工作的环境的所有内容)：用户数量、分布、技术成熟度(用户和支持它的人员)、数据敏感性、业务性质以及系统如何与此相关-系统是处理实时医疗记录(生死攸关的问题)还是wiki?
• Non-Functional要求(a)：按优先级顺序确定前3名，因为这将是做出架构决策的关键指南。性能是最重要的吗？或者是安全措施？可用性？它们将由context.
• Non-Functional需求驱动(b)：它们也将由上下文驱动，但它们也提供(希望是可测试的)您需要达到的标记:多快，多可用，多可用，如何处理DR.

您应该能够提供的输出(因此，请考虑如何做到这些)包括：

• 某种解决方案架构定义。通常是一个正式的文档，但可能不需要。它应该包括与解决方案/问题/上下文相关的“视图”的信息:系统组件的逻辑视图(包括外部接口和您与之交互的系统)，系统组件将部署在何处的物理视图，如果您正在编写软件，您还需要描述如何将软件划分为可以部署的物理包、安全性、数据等等。
• 决策注册表:这将是一个活动注册表，您可以在项目的整个生命周期中将其添加到其中。用它来解释为什么做出了某些决定。这既可以在任何时候遇到挑战时保护你，也可以在6个月后当问题出现时帮助你/他人，你需要记住为什么你做了你所做的事情。

详细信息和设计

设计是你进入详细细节的地方，这可能包括在对象级别使用的模式，等等。这是您可能会发现自己提供参考实现的时间和地点:这是我们需要构建服务结构的方式，等等。

Answer 2

恐怕唯一真正的答案是练习；练习；练习。然而，我发现，当考虑不同领域之间的主题分布时，不断提醒自己三件事是有用的。

首先，请始终牢记您当前正在处理的任务级别。当考虑架构/设计的任何部分时，(对你自己)不断地说-这是一个适合这项任务的主题吗？(例如，我目前正在处理的项目需要解析器解析器的规范。这对体系结构很重要，但我很长一段时间都忘记了程序的输出是一个解析器，而不是语法的描述。)

其次，简化。我发现好的设计和好的架构往往都很简单--它们往往会导致“啊哈”的时刻--很明显，这是要走的路。这确实意味着(特别是在架构上工作时)准备好重新组织事物；从架构中删除东西-到一个“好的想法片段”位置，这样你就可以回到它们。还要记住，如果你有适当的抽象级别，那么即使是一个非常简单的系统描述也会有很大的深度。

第三，跟踪你的想法，你的想法，你的建议。这不需要非常详细-我使用文本日记格式，在我创建条目时标记它们的时间戳。我捕捉当时看起来很重要的东西。我不经常回想它，但我确实会回想起来，特别是当我的思维有了突破的时候。这个工具是我个人使用的-它不是我提供给其他人使用的东西。

最后，在架构上工作时，深入研究设计很可能是这个过程的一部分。一个人需要真正理解你试图满足的含义和要求，有时唯一的方法是深入了解。只需记住浮出水面，准备将深入研究的结果放在其他地方，并将您的调查结果集成到您的体系结构中-当然是在适当的抽象级别。

编辑：

就工具而言，我已经找到了帮助思考大多数帮助的工具。思维导图软件，如Mind Manager；UML工具，如您提到的；白板类型的工具，其中项目可以放置，移动和修改，使用与白板相同的工具；以及(如果在企业环境中)头脑风暴会议软件。我不能给出后面这些工具的参考，因为我的知识已经严重过时了。同样，把你所有的笔记放在版本控制下，按任务划分到不同的项目中可能会有所帮助。

作为我最初提到的项目的一部分，我正在尝试开发一些工具，这些工具将有助于这类过程。这些工具将通过参考架构、设计和构建过程的模型来集成。然而，这是一个娱乐项目，只有一个开发人员，我自己，我还没有到可以提供工具的地步。