在编写任何代码之前，您如何规划应用程序的体系结构？
我要做的一件事就是在编写任何代码之前计划应用程序的体系结构。
我并不是说收集需求来缩小应用程序需要做什么，而是有效地思考一个布局整个类，数据和stream程结构的好方法，并重复这些想法，以便我有一个可信的计划甚至在打开IDE之前的行动。 目前，只要打开IDE，创build一个空白的项目，开始写点东西，让devise从那里“长出来”，都很容易。
我收集UML是这样做的一种方法，但我没有经验，所以它似乎有点模糊。
在编写任何代码之前， 您如何规划应用程序的体系结构？ 如果UML是要走的路，你可以推荐一个简洁而实用的小应用程序的开发者介绍吗？
我感谢你的意见。
我真的发现，首先写在纸上或白板上是非常重要的。 然后，如果你愿意的话，转移到UML，但是没有什么比第一个手工绘制的灵活性更好。
我认为以下几点：
- 系统应该做什么，也就是系统正在试图解决的问题是什么
- 谁是客户，他们的愿望是什么
- 什么系统必须与整合
- 有没有遗留的方面需要考虑
- 什么是用户interractions
- 等等…
然后我开始把系统看作一个黑盒子，并且：
- 这个黑匣子需要发生什么样的交互
- 在黑匣子内部需要发生什么样的行为，也就是黑盒子的相互作用需要发生什么，才能在更高的层次上performance出所需的行为，例如接收和处理来自预留系统的input消息，更新数据库等。
然后，这将开始给你一个由各种内部黑匣子组成的系统的视图，每个黑匣子可以以相同的方式进一步分解。
UML很好地代表这样的行为。 您可以使用UML的许多组件中的两个来描述大多数系统，即：
- 类图，和
- 序列图。
如果需要描述的行为有任何并行性，你也可能需要活动图。
学习UML的一个很好的资源是Martin Fowler出色的书籍“UML Distilled”（ 亚马逊链接 – 用于脚本kiddie链接纳粹的消息（ – ：）。）这本书让你快速浏览每个组件的基本部分UML。
哦。 我所描述的几乎是Ivar Jacobson的方法。 Jacobson是OO的三个朋友之一。 事实上，UML最初是由另外两个人组成的，他们是三个朋友，Grady Booch和Jim Rumbaugh
如果您正在开发.NET，Microsoft刚刚发布了应用程序体系结构指南2.0b1 （作为免费电子书！）。 在编写任何代码之前，它提供了关于规划你的体系结构的很好的信息。
如果你绝望，我希望你可以使用它的大块非基于.NET的体系结构。
我会在前面说，我主要是做Web开发，其中大部分架构已经提前决定了（WebForms，现在是MVC），我的大部分项目都是相当小的，一人一年的时间不到一年。 我也知道，我将有一个ORM和DAL分别处理我的业务对象和数据交互。 最近，我已经转向使用LINQ，所以“devise”中的大部分都变成了通过DBMLdevise器进行数据库devise和映射。
通常，我以TDD（testing驱动开发）方式工作。 我不花很多时间在build筑或devise细节上工作。 我通过故事收集用户与应用程序的整体交互。 我使用这些故事来devise交互devise并发现应用程序的主要组件。 在与客户的这个过程中，我做了很多白板工作 – 有时如果他们看起来足够重要，可以用数码相机捕捉细节，以保持图表的forms。 主要是我的故事在维基中以故事forms被捕获。 最终，这些故事被组织到版本和迭代中。
这个时候我通常对这个架构有一个很好的想法。 如果它很复杂或者有不寻常的点点 – 与我的正常实践不同的东西 – 或者我正在和其他人（不是典型的）一起工作，我会在白板上绘制一些东西。 复杂的交互也是如此 – 我可以在白板上devise页面布局和stream程，保留它（或通过摄像头捕捉），直到完成该部分。 一旦我对我要去的地方以及需要做的事情有一个大概的了解，我会开始为第一个故事写testing。 通常情况是这样的：“好的，我需要这些类，我将从这个开始，它需要这样做。” 然后，我开始愉快地TDDing，架构/devise从应用程序的需求增长。
定期地，我会发现自己想再写一些代码，或者认为“这真的有味道”，我会重构我的devise，以消除重复或用更优雅的东西来取代臭味。 大多数情况下，我很关心如何遵循良好的devise原则来降低function。 我发现，使用已知的模式，并在你去的时候注意好的原则，工作得很好。
http://dn.codegear.com/article/31863
我使用UML，并发现该指南非常有用和易于阅读。 让我知道你是否需要不同的东西。
“白板，草图和便笺是优秀的devise工具，复杂的build模工具比照明更容易分散注意力。” 来自Venkat Subramaniam和Andy Hunt的敏捷开发人员的实践 。
UML是一个符号。 这是一种logging你devise的方式，但不是（在我看来）做devise。 如果你需要写东西，我会推荐UML，不是因为它是“最好的”，而是因为它是其他人可能已经知道如何阅读的标准，而且它打败了你自己的“标准”。
我认为对UML的最好的介绍仍然是由Martin Fowler提供的UML Distilled ，因为它很简洁，给出了在哪里使用它的实际指导，并且明确表示你不必购买整个UML / RUP的故事，有用
做devise很难。它不能真正被捕获在一个StackOverflow的答案。 不幸的是，这些年来我的devise技巧已经发展，所以我没有一个我可以推荐的来源。
然而，我发现一个有用的模型是健壮性分析（谷歌为它，但这里有一个介绍）。 如果你有你的系统应该做的用例，一个涉及到什么东西的领域模型，那么我发现健壮性分析是一个连接两者的有用工具，并且计算出系统的关键组成部分是什么。
但最好的build议是广泛阅读，认真思考和实践。 这不是一个纯粹的可教技能，你必须真正做到这一点。
我不相信在实施之前可以提前计划任何事情。 我有10年的经验，但只有4家公司（包括一个公司的2个站点，几乎是极地的对立面），几乎所有的经验都是在观看庞大的团队**发生。 我开始认为像重构这样的东西实际上是做事的最好方式，但是同时我意识到我的经验是有限的，而且我可能只是对我所看到的做出反应。 我真的很想知道如何获得最好的体验，所以我能得出正确的结论，但似乎没有捷径，它只是涉及很多时间，看到人们做错事情:(我我真的很想在一家公司工作，让人们做正确的事情（如成功的产品部署所certificate的），知道我是否只是一个逆向的混蛋，或者我真的像我想的那么聪明我是。
我不够聪明，提前计划一点点。 当我提前计划的时候，我的计划总是出错，但是现在我已经花了n天的时间来计划糟糕的计划。 我的限制似乎是在白板上15分钟左右。
基本上，我尽我所能去确定自己是否朝着正确的方向前进。
我看着我的devise中的关键问题：当A做B到C时，D会快吗？ 如果不是，我们需要一个不同的devise。 这些问题中的每一个都可以用秒杀来回答。 如果尖刺看起来不错，那么我们有devise，现在是时候扩大它。
我尽可能快地获得一些真正的客户价值，所以客户可以告诉我应该去哪里。
因为我总是把事情搞错，所以我依靠重构来帮助我把它们弄对。 重构是有风险的，所以我必须随时编写unit testing。 事后编写unit testing很难，因为耦合，所以我先写testing。 对这些东西保持严格的纪律是很难的，而一个不同的大脑以不同的方式看待事情，所以我喜欢和我一起编写好友。 我的编码哥们有一个鼻子，所以我经常淋浴。
我们称之为“极限编程”。
我不同意：UML可以用于应用程序架构，但更经常用于技术架构（框架，类或序列图，…），因为这些图可以很容易地与开发同步。
应用程序体系结构是在您采用某些function规范（描述操作的本质和stream程，而不对未来的实现做出任何假设）时发生的，并将其转换为技术规范。
这些规范代表了实现一些业务和function需求所需的应用程序 。
因此，如果您需要处理几个大型金融投资组合（function规格），您可以确定您需要将该大规格分为：
- 调度员将这些繁重的计算分配给不同的服务器
- 一个启动器，以确保所有的计算服务器启动和运行之前，开始处理这些投资组合。
- 一个GUI能够显示正在发生的事情。
- 一个“通用”组件开发具体的投资组合algorithm，独立于应用程序架构的其余部分，以便于unit testing，还有一些function和回归testing。
所以基本上，考虑应用程序体系结构是决定你需要以一种连贯的方式来开发什么样的“文件组”（你不能在同一组文件中开发一个启动器，一个GUI，一个调度程序……）将无法以同样的速度发展）
当一个应用程序体系结构被很好地定义时，它的每个组件通常是一个configuration组件的好候选，也就是一组文件，它可以被全部版本化为一个VCS（版本控制系统），这意味着它的所有文件都将每次需要logging该应用程序的快照时，将其标记在一起（再次，将难以标记所有的系统，其每个应用程序不能同时处于稳定状态）
我试图把我的想法分解成两个方面：performance我想要操纵的东西，以及我打算怎样处理它们。
当我试图对我想操纵的东西进行build模时，我想出了一系列独立的项目定义 – 一个电子商务网站将具有一个SKU，一个产品，一个客户等等。 我还会有一些非物质的东西，我正在使用一个订单或一个类别。 一旦我拥有了系统中所有的“名词”，我就会创build一个领域模型来展示这些对象是如何相互关联的 – 一个订单有一个顾客和多个SKU，许多SKUS被分组成一个产品，所以上。
这些领域模型可以表示为UML领域模型，类图和SQL ERD。
一旦我find了系统的名词，我就转向动词 – 例如，这些项目中的每一个都要执行的操作。 这些通常很好地映射到我的function需求中 – 我发现的最简单的方法是UML序列，活动或协作图或泳道图。
认为这是一个反复的过程是很重要的。 我会做一个域的一个angular落，然后工作，然后回去。 理想情况下，我将有时间编写代码，以便随着时间的推移尝试一些东西 – 你永远不希望devise在应用程序之前过多。 如果你认为你正在为所有事情build立完整的，最终的架构，这个过程通常是很糟糕的。 实际上，你所要做的就是build立团队在发展过程中共同分享的基本基础。 你们大多为团队成员创build了一个共享的词汇来描述这个系统，而不是为了如何去做而制定法律。
在编写代码之前，我发现自己在编写系统时遇到了麻烦。 只是简单地匆匆一瞥一些你以后才意识到的组件，比你想像的要复杂得多。
一个解决办法就是努力尝试。 随处写UML。 经过每一堂课。 想想如何与其他课程交互。 这很难做到。
我喜欢做的是首先进行总体概述。 我不喜欢UML，但是我喜欢绘制图表来获得重点。 然后我开始执行它。 即使我只是用空白的方法写出课程结构，我也经常看到我早先错过的东西，于是我更新了devise。 正如我在编码，我会意识到我需要做不同的事情，所以我会更新我的devise。 这是一个反复的过程 。 “先devise一切，然后再实现”的概念被称为瀑布模型，我认为其他人已经表明这是做软件的一个坏方法。
尝试Archimate。
我一直在做架构。 我使用BPML来首先优化业务stream程，然后使用UML来捕获各种细节。 第三步一般是ERD！ 当你完成了BPML和UML，你的ERD将会相当稳定！ 没有计划是完美的，没有抽象是100％。 规划重构，目标是尽可能地减less重构！
