Answers:
我考虑以下几点：
然后，我开始将系统视为黑匣子，然后：
然后，将开始为您提供一个由各种内部黑匣子组成的系统视图，每个黑匣子都可以用相同的方式进一步分解。
UML很好地代表了这种行为。您可以仅使用UML的许多组件中的两个来描述大多数系统，即：
如果需要描述行为中的任何并行性，那么您可能还需要活动图。
马丁·福勒（Martin Fowler）的出色著作“ UML Distilled”（亚马逊链接-已针对那里的脚本kiddie link nazis（-：）进行了消毒）是一本很好的学习UML的资源。 UML。
哦。我所描述的几乎是Ivar Jacobson的方法。雅各布森是OO的三个朋友之一。实际上，UML最初是由另外三个人Grady Booch和Jim Rumbaugh共同开发的，这三个人组成了三个好友。
您绝对应该看一下史蒂夫·麦康奈尔（Steve McConnell）的《代码完成》，尤其是他关于“建筑设计”的赠品章节。
您可以从他的网站下载：
如果您正在开发.NET，Microsoft刚刚出版了（作为免费电子书！）《应用程序体系结构指南2.0b1》。它在编写任何代码之前提供了大量有关计划架构的非常好的信息。
如果您不顾一切，我希望您可以将其大块用于非基于.NET的体系结构。
首先，我要说的是，我主要进行Web开发，因为许多架构都是预先确定的（WebForms，现在是MVC），而我的大多数项目都是相当小的单人工作，不到一年的时间。我也知道，我将有一个ORM和DAL分别处理我的业务对象和数据交互。最近，我已经为此使用LINQ，因此许多“设计”都通过DBML设计器成为数据库设计和映射。
通常，我以TDD（测试驱动开发）方式工作。我不会花很多时间在建筑或设计细节上。我确实通过故事收集了用户与应用程序的整体交互。我使用这些故事来设计交互设计并发现应用程序的主要组件。在此过程中，我与客户进行了很多白板交易-有时用数码相机捕获细节，如果它们看起来足够重要，可以保持图表形式。我的故事主要是在Wiki中以故事形式捕获的。最终，故事被组织成发行和迭代。
到这个时候，我通常对体系结构有了一个很好的了解。如果很复杂或有不寻常的地方-与我的常规做法有所不同-或我正在与其他人（不是典型的人）一起工作，我将在白板上画图。复杂的交互也是如此-我可以在白板上设计页面布局和流程，保留它（或通过相机捕获），直到完成该部分为止。一旦我对要去的方向和首先需要做的事情有了一个大致的了解，我将开始为第一个故事编写测试。通常，这就像：“好吧，要做到这一点，我将需要这些类。我将从这一类开始，并且它需要做到这一点。” 然后，我开始愉快地进行TDDing，并且架构/设计从应用程序的需求中发展而来。
定期地，我会发现自己想重新编写一些代码，或者认为“这确实很香”，我将重构设计以消除重复，或者用更优雅的方式替换这些臭味。通常，我关注在遵循良好设计原则的同时降低功能性。我发现使用已知的模式并在遵循过程中注意良好的原则效果很好。
http://dn.codegear.com/article/31863
我使用UML，发现该指南非常有用且易于阅读。让我知道您是否需要其他东西。
UML是一种表示法。这是一种记录您的设计的方法，但（我认为）不是一种设计。但是，如果您需要写下来，我会推荐UML，不是因为它是“最好的”，而是因为它是其他人可能已经知道如何阅读的标准，并且它胜过发明自己的“标准”。
我认为，关于UML的最佳介绍仍然是Martin Fowler撰写的《UML Distilled》，因为它简洁明了，为使用它提供了实用指导，并且很显然，您不必为整个UML / RUP故事买单。有用
做设计很困难，实际上并不能在一个StackOverflow答案中捕捉到。不幸的是，我的设计技能（例如它们）已经发展了多年，因此我没有一个可以参考的资源。
然而，一个模型，我发现有用的鲁棒性分析（谷歌，但有一个前奏这里）。如果您有系统应该做什么的用例，涉及到什么的领域模型，那么我发现健壮性分析是将两者联系起来并确定系统的关键组成部分的有用工具。 。
但是最好的建议被广泛阅读，认真思考和实践。这不是纯粹的可教技能，您必须真正做到这一点。
我不够聪明，无法提前计划。当我确实提前计划时，我的计划总是会出错，但是现在我已经花了n天时间制定了糟糕的计划。我的极限似乎在白板上大约15分钟。
基本上，我会花很少的精力来确定我是否朝着正确的方向前进。
我在设计时考虑了一些关键问题：当A到B时，对于D而言，它是否足够快？如果没有，我们需要一个不同的设计。这些问题中的每一个都可以一口气回答。如果峰值看起来不错，那么我们就有了设计，是时候对其进行扩展了。
我编写代码的方向是尽快获得真正的客户价值，以便客户可以告诉我应该去哪里。
因为我总是会出错，所以我依靠重构来帮助我正确处理。重构是有风险的，因此我必须随时编写单元测试。由于耦合而很难编写单元测试，因此我首先编写测试。对这些东西保持纪律是很难的，而且不同的大脑对事物的看法也不同，所以我喜欢和我一起做一个伙伴。我的编码伙伴有鼻子，所以我要定期洗澡。
我们称之为“极限编程”。
“白板，草图和便利贴是出色的设计工具。复杂的建模工具往往比照亮会分散注意力。” 从Venkat Subramaniam和Andy Hunt的敏捷开发者的实践谈起。
我不相信有什么可以在实施之前预先计划。我有10年的经验，但是只有4家公司（其中1家公司有2个站点，几乎是相反的对立面），而且我的几乎所有经验都是在观察巨大集群方面****** **发生。我开始认为诸如重构之类的东西确实是最好的处理方式，但是与此同时，我意识到自己的经验有限，而且我可能只是对自己所见即所得做出反应。我真正想知道的是如何获得最佳体验，以便能够得出正确的结论，但是似乎没有捷径可走，而这只是涉及到看到人们在做错事情的大量时间:(。我真的很想在一家人做正确的公司工作（成功的产品部署证明了这一点），
我要不同的是：UML可以用于应用程序体系结构，但更经常用于技术体系结构（框架，类或序列图等），因为在这里，这些图可以最轻松地与开发保持同步。
当您采用一些功能规范（在不对未来实现做任何假设的情况下描述了操作的性质和流程）并将它们转换为技术规范时，就会发生应用程序体系结构。
这些规范代表了应用程序，你需要实现一些业务和功能需求。
因此，如果您需要处理多个大型金融投资组合（功能规范），则可以确定需要将该大型规范划分为：
所以基本上，考虑一下 应用程序体系结构是决定需要以一致的方式开发哪些“文件组”（您不能在同一组文件中开发启动器，GUI，调度程序……）：将无法以相同的速度发展）
定义好应用程序体系结构后，通常可以将其每个组件用作配置组件的候选对象，即一组文件，这些文件可以全部版本化为VCS（版本控制系统），这意味着其所有文件都可以每次需要记录该应用程序的快照时都将它们标记在一起（同样，很难标记所有系统，其每个应用程序不能同时处于稳定状态）
我从事建筑已有一段时间了。我使用BPML首先优化业务流程，然后使用UML捕获各种细节！第三步通常是ERD！到您完成BPML和UML时，您的ERD将相当稳定！没有计划是完美的，没有抽象将是100％。规划重构，目标是尽可能减少重构！
我试图将我的思想分解为两个方面：我要操纵的事物的表示形式以及我打算如何处理它们。
当我试图对要操纵的东西进行建模时，我提出了一系列离散的项定义-电子商务站点将具有SKU，产品，客户等。我还将处理一些与我无关的东西-订单或类别。在系统中拥有所有“名词”之后，我将创建一个域模型，该模型显示这些对象之间的相互关系-订单有一个客户和多个SKU，许多功能组合到一个产品中，如此上。
这些域模型可以表示为UML域模型，类图和SQL ERD。
一旦弄清了系统的名词，我就继续进行动词-例如，这些项中的每一项都要执行的操作才能提交命令。这些通常可以很好地映射到我的功能需求中的用例-表达我发现的最简单的方法是UML序列，活动或协作图或泳道图。
将其视为一个迭代过程很重要；我将在领域的一个小角落，然后进行操作，然后再返回。理想情况下，随着我的前进，我将有时间编写代码来尝试一些东西-您永远都不希望设计在应用程序之前走得太远。如果您认为要为所有内容构建完整的最终体系结构，则此过程通常会很糟糕。实际上，您要做的只是建立团队在开发过程中将共享的基本基础。您主要是在为团队成员创建共享词汇表以供他们在描述系统时使用，而不是就如何完成工作制定法律。
我发现自己在对系统进行编码之前无法全面考虑。只粗略浏览一下某些组件，这太容易了，您后来才意识到它们比您想象的要复杂得多。
一种解决方案是尽力而为。随处编写UML。上每一堂课。考虑一下它将如何与您的其他班级互动。这很难做到。
我喜欢做的是首先进行总体概述。我不喜欢UML，但我确实喜欢能说明问题的绘图。然后，我开始实施它。即使我只是用空方法写出类结构，我也经常看到我以前错过的东西，因此我更新了设计。在编写代码时，我会意识到我需要做一些不同的事情，因此我将更新自己的设计。这是一个反复的过程。“首先设计一切，然后实施全部”的概念被称为瀑布模型，我认为其他人已经证明这是一种不良的软件开发方式。