如何分别确定架构和设计的抽象和范围？
我正处于项目的架构阶段。我的挑战是我目前无法保持一定程度的抽象。我经常潜入我们通常在设计中涉及的领域。
我不知道在哪里停止思考&阐述......因此我最终阐明了解决方案的非常详细的细节，这些细节将直接供程序员使用。在这个过程中，我失去了大局（愿景），并延长了专门用于建筑目的的时间。
当我在解决架构问题时，是否有任何方法/方法论/途径可以用来将自己限制在架构的范围内？同样，当我处于设计阶段时，是否可以将自己限制在架构的范围内？
I am in the architecture phase of my project. My challenge is that I am unable to maintain a certain level of abstraction at present. I often creep into areas that we generally address as part of design.
I don't know where to stop thinking & elaborating ... therefore I end up articulating very fine details of the solution which will directly be usable to the programmers. In the process I am losing the big picture (vision) and stretching time exclusively dedicate for the purpose of architecture.
Are there any ways / methodologies / approaches that can be used to restrict myself within boundaries of architecture while I am addressing it and likewise for design when I am in design phase?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
退后一步 - 您正处于架构阶段，那么该阶段需要产生哪些可交付成果？您知道您的项目中需要交付给哪些利益相关者吗？ - 他们需要/期望什么？我想说的一点是，如果你没有清楚地确定你需要做什么——它就不会完成（无论你使用什么方法）。
限制/保持目标
一个好的架构将经历 3 个级别，这些是方法的良好基础：
对于所有这些，您应该能够找到支持您的方法的参考架构或某种“现有技术”。
这 3 个步骤的输入可能相当大，并且应包括：
您应该能够提供的输出（因此请考虑如何做到这些）包括：
详细信息&设计
设计是您了解详细细节的地方，这可能包括在对象级别使用的模式等等。这是您可能会发现自己提供参考实现的时间和地点：这就是我们需要构建我们的服务等的方式。
Take a step back - you're at the architecture phase, so what are the deliverables that this phase needs to produce? Do you know who the stakeholders are in your project that you need to deliver to? - what they need / expect? The point I want to make is that if you haven't clearly identified what it is you need to do - it won't get done (regardless of what method you use).
Restrictions / Keeping yourself on target
A good architecture will go through 3 levels, and these are a good basis for an approach:
For all of these you should be able to find reference architectures or "prior art" of some kind which backs up your approach.
Inputs into these 3 steps can be considerable, and should include:
Outputs you should be able to provide (so think about how you can do these) include:
Details & Design
Design is where you get into detailed specifics, this could include patterns to be used at the object level, and so on. This is the time and place where you might find yourself providing reference implementations: this is how we need to structure our services, etc.
恐怕唯一真正的答案就是实践；实践;实践。然而，我发现在考虑不同领域之间的主题分配时，不断提醒自己三件事是有用的。
首先，请始终牢记您当前正在执行的任务级别。当考虑架构/设计的任何部分时，不断地（对自己）说——这是否适合这项任务的主题。 （举个例子，我目前正在做的项目，需要一个parser解析器的规范。这对于架构来说是至关重要的，但我很长一段时间都没有记住程序的输出是一个解析器，而不是语法描述。）
其次，简化。我发现好的设计和好的架构都倾向于简单 - 它们往往会带来“顿悟”时刻 - 显然这是要走的路。这确实意味着（特别是在从事建筑工作时）要准备好重组事物；从架构中删除一些东西 - 放入“好主意片段”位置，以便您可以返回它们。还要记住，如果您具有适当的抽象级别，那么即使是非常简单的系统描述也会具有相当的深度。
第三，记录你的想法、想法和建议。这不需要非常复杂——我使用文本日记格式，在创建条目时为其添加时间戳。我捕捉当时看来很重要的事情。我不会经常回顾它，但我确实会回顾，特别是当我的思维出现中断时。该工具仅供我个人使用 - 我不会向其他人提供该工具。
最后，在从事建筑工作时过于深入地研究设计很可能是这个过程的一部分。人们需要真正理解你想要满足的含义和要求，有时做到这一点的唯一方法就是深入了解。只要记住让自己浮出水面，准备好将深入研究的结果存放在其他地方，并将调查结果整合到你的架构中——当然是在适当的抽象级别上。
编辑：
就工具而言，我已经找到了可以帮助思考大多数帮助的工具。思维导图软件，例如 Mind Manager； UML 工具，例如您提到的；白板类型工具，可以使用与白板相同的功能来放置、移动和修改项目；以及（如果在企业环境中）头脑风暴会议软件。我无法提供后面这些工具的参考，因为我的知识已经严重过时了。此外，将所有笔记置于版本控制之下，按任务分为不同的项目也会有所帮助。
作为我最初提到的项目的一部分，我正在尝试开发一些有助于此类过程的工具。这些工具将通过参考架构、设计和构建过程的模型来集成。然而，这是一个娱乐项目，只有我自己一个开发人员，而且我还没有达到可以提供工具的程度。
I am afraid the only real answer is practice; practice; practice. However, I found that when considering distribution of topics between the different areas, it is useful to continually remind yourself of three things.
Firstly, try to keep in mind, all the time, what level of task you are currently working on. When considering any part of the architecture/design, keep saying (to yourself) - is this an appropriate topic for THIS task. (As an example, the project I am currently working on, requires the specification of a parser parser. This is essential to the architecture, but I failed to remember for a long time that the output of the program was a parser, rather than the description of the grammar.)
Secondly, simplify. I have found that both good design and good architecture tend to be simple - they tend to lead to an "aha" moment - it is obvious that this is the way to go. This does mean (particularly when working on architecture) to be prepared to reorganise things; to remove things from the architecture - into a "good idea fragment" location, so that you can go back to them. Remember also that if you have the appropriate level of abstraction, then even a very simple system description will have substantial depth.
Thirdly, keep track of your thinking, your ideas, your proposals. This need not be very elaborate - I use a textual diary format, timestamping entries as I make them. I capture things that seem to be significant at the time. I don't go back to it a lot, but I do go back, particularly if there is a break in my thinking. This tool is for my own personal use - it is not something that I make available to others.
Finally, delving too deep into design when working on architecture, may well be part of the process. One needs to really understand the implications and requirements you are trying to satisfy, and sometimes the only way to do this is to go deep. Just remember to surface yourself, be prepared to park elsewhere the results of going deep, and integrate the results of your investigations into your architecture - at an appropriate level of abstraction of course.
EDIT:
As far as tooling goes, I have found tools to aid thinking of most assistance. Mind mapping software such as Mind Manager; UML tools such as you mention; whiteboard type tools, where items can be placed and moved around and amended with the same facility as a whiteboard; and (if in corporate environment) brainstorming meeting software. I can't give references to these latter tools, because my knowledge is severely out of date. Also, putting all your notes under version control, separated by task into different projects can be of help.
As part of the project I mentioned originally, I am trying to develop a number of tools which will aid in this sort of process. The tools will be integrated by reference to a models of the architectural, design, and build processes. However, this is a recreational project with a sole developer, myself, and I am not yet at a point where I can provide tools.