blocks|key|357630|text|http://dn.codegear.com/article/31863|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|357631|我使用UML，并发现该指南非常有用且易于阅读。如果你需要不同的东西，请告诉我。|357632|entityMap|0|LINK|mutability|MUTABLE|url^0|0|10|0|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@$A|N|B|O|1|P]]|C|$]]|$1|D|3|E|5|6|7|Q|8|@]|9|@]|C|$]]|$1|F|3|-4|5|6|7|R|8|@]|9|@]|C|$]]]|G|$H|$5|I|J|K|C|$L|4]]]]

<a href="http://dn.codegear.com/article/31863" rel="noreferrer">http://dn.codegear.com/article/31863</a>

I use UML, and find that guide pretty useful and easy to read. Let me know if you need something different.

blocks|key|3356055|text|如果你正在为.NET开发，微软刚刚出版了(作为一个免费的电子书！)Application+Architecture+Guide+2.0b1。在编写任何代码之前，它提供了大量关于规划架构的非常好的信息。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|3356056|如果你已经走投无路了，我希望你可以在非基于.NET的架构中使用大量的代码。|3356057|entityMap|0|LINK|mutability|MUTABLE|url|http://www.infoq.com/news/2008/11/App-Architecture-Guide-2.0^0|X|10|0|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@$A|O|B|P|1|Q]]|C|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@]|C|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|C|$]]]|G|$H|$5|I|J|K|C|$L|M]]]]

If you're developing for .NET, Microsoft have just published (as a free e-book!) the <a href="http://www.infoq.com/news/2008/11/App-Architecture-Guide-2.0" rel="noreferrer">Application Architecture Guide 2.0b1</a>. It provides loads of really good information about planning your architecture before writing any code.

If you were desperate I expect you could use large chunks of it for non-.NET-based architectures.

blocks|key|357697|text|UML是一种符号。这是一种记录你的设计的方式，但不是(在我看来)做设计的方式。如果你需要写下来，我会推荐UML，不是因为它是“最好的”，而是因为它是一个别人可能已经知道如何阅读的标准，而且它胜过发明你自己的“标准”。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|357698|我认为对UML最好的介绍仍然是Martin+Fowler的UML+Distilled，因为它很简洁，给出了关于在哪里使用它的实用指南，并且清楚地表明，您不必购买整个UML/RUP故事才能使用它。|offset|length|357699|做设计是hard.It不可能真的在一个StackOverflow答案中被捕获。不幸的是，我的设计技能，比如它们，已经随着时间的推移而发展，所以我没有一个资源可以让你参考。|357700|然而，我发现一个有用的模型是健壮性分析(google+for+it，但有一个入门here)。如果你有系统应该做什么的用例，涉及什么的领域模型，那么我发现健壮性分析是一个有用的工具，可以将两者联系起来，并找出系统的关键组件需要是什么。|357701|但是最好的建议是广泛阅读，努力思考和实践。这不是一项纯粹可以传授的技能，你必须真正去做。|357702|entityMap|0|LINK|mutability|MUTABLE|url|https://rads.stackoverflow.com/amzn/click/com/020165783X|1|http://iconixprocess.com/iconix-process/analysis-and-preliminary-design/robustness-analysis/^0|0|T|D|0|0|0|14|4|1|0|0^^$0|@$1|2|3|4|5|6|7|V|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|W|8|@]|9|@$D|X|E|Y|1|Z]]|A|$]]|$1|F|3|G|5|6|7|10|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|11|8|@]|9|@$D|12|E|13|1|14]]|A|$]]|$1|J|3|K|5|6|7|15|8|@]|9|@]|A|$]]|$1|L|3|-4|5|6|7|16|8|@]|9|@]|A|$]]]|M|$N|$5|O|P|Q|A|$R|S]]|T|$5|O|P|Q|A|$R|U]]]]

UML is a notation. It is a way of recording your design, but not (in my opinion) of doing a design. If you need to write things down, I would recommend UML, though, not because it's the "best" but because it is a standard which others probably already know how to read, and it beats inventing your own "standard".

I think the best introduction to UML is still <a href="https://rads.stackoverflow.com/amzn/click/com/020165783X" rel="nofollow noreferrer" rel="nofollow noreferrer">UML Distilled</a>, by Martin Fowler, because it's concise, gives pratical guidance on where to use it, and makes it clear you don't have to buy into the whole UML/RUP story for it to be useful

Doing design is hard.It can't really be captured in one StackOverflow answer. Unfortunately, my design skills, such as they are, have evolved over the years and so I don't have one source I can refer you to.

However, one model I have found useful is robustness analysis (google for it, but there's an intro <a href="http://iconixprocess.com/iconix-process/analysis-and-preliminary-design/robustness-analysis/" rel="nofollow noreferrer">here</a>). If you have your use-cases for what the system should do, a domain model of what things are involved, then I've found robustness analysis a useful tool in connecting the two and working out what the key components of the system need to be.

But the best advice is read widely, think hard, and practice. It's not a purely teachable skill, you've got to actually do it.

blocks|key|357029|text|我真的发现在纸上或白板上写作的第一步是非常重要的。然后，如果您愿意，可以使用UML，但没有什么比一开始就手工绘制它的灵活性更好的了。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|357030|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I really find that a first-off of writing on paper or whiteboard is really crucial. Then move to UML if you want, but nothing beats the flexibility of just drawing it by hand at first.

blocks|key|3143307|text|我首先要说的是，我主要做web开发，其中大部分架构已经提前确定(WebForms，现在的MVC)，我的大多数项目都是相当小的，一个人的工作，只需要不到一年的时间。我还知道，我将使用ORM和DAL分别处理业务对象和数据交互。最近，我转而使用LINQ来做这件事，所以很多“设计”都是通过DBML设计器来进行数据库设计和映射的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3143308|通常，我以TDD+(测试驱动开发)的方式工作。我不会花太多时间在架构或设计细节上。我确实通过故事收集了用户与应用程序的整体交互。我使用这些故事来进行交互设计，并发现应用程序的主要组件。在与客户的这个过程中，我做了很多白板--有时用数码相机捕捉细节，如果它们看起来足够重要，可以保持在图表形式。我的故事主要是在维基中以故事的形式被捕获的。最终，故事被组织成发布和迭代。|3143309|到这个时候，我通常对架构有了很好的了解。如果事情很复杂，或者有一些不寻常的地方--与我的正常实践不同--或者我正在与其他人(不是典型的)一起工作，我会用图表表示(同样是在白板上)。对于复杂的交互也是如此--我可能会在白板上设计页面布局和流程，保留它(或通过相机捕捉)，直到我完成该部分。一旦我对我要去哪里以及首先需要做什么有了大致的想法，我将开始为第一个故事编写测试。通常是这样的：“好的，要做到这一点，我需要这些类。我将从这个类开始，它需要这样做。”然后，我愉快地开始TDDing，架构/设计根据应用程序的需求而增长。|3143310|定期地，我会发现自己想要重新编写一些代码，或者认为“这真的很难闻”，我会重构我的设计，以消除重复或用更优雅的东西替换难闻的部分。大多数情况下，我关心的是在遵循良好的设计原则的同时降低功能。我发现，使用已知的模式，并在进行过程中注意好的原则，效果很好。|3143311|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

I'll preface this by saying that I do mostly web development where much of the architecture is already decided in advance (WebForms, now MVC) and most of my projects are reasonably small, one-person efforts that take less than a year. I also know going in that I'll have an ORM and DAL to handle my business object and data interaction, respectively. Recently, I've switched to using LINQ for this, so much of the "design" becomes database design and mapping via the DBML designer.

Typically, I work in a TDD (test driven development) manner. I don't spend a lot of time up front working on architectural or design details. I do gather the overall interaction of the user with the application via stories. I use the stories to work out the interaction design and discover the major components of the application. I do a lot of whiteboarding during this process with the customer -- sometimes capturing details with a digital camera if they seem important enough to keep in diagram form. Mainly my stories get captured in story form in a wiki. Eventually, the stories get organized into releases and iterations.

By this time I usually have a pretty good idea of the architecture. If it's complicated or there are unusual bits -- things that differ from my normal practices -- or I'm working with someone else (not typical), I'll diagram things (again on a whiteboard). The same is true of complicated interactions -- I may design the page layout and flow on a whiteboard, keeping it (or capturing via camera) until I'm done with that section. Once I have a general idea of where I'm going and what needs to be done first, I'll start writing tests for the first stories. Usually, this goes like: "Okay, to do that I'll need these classes. I'll start with this one and it needs to do this." Then I start merrily TDDing along and the architecture/design grows from the needs of the application.

Periodically, I'll find myself wanting to write some bits of code over again or think "this really smells" and I'll refactor my design to remove duplication or replace the smelly bits with something more elegant. Mostly, I'm concerned with getting the functionality down while following good design principles. I find that using known patterns and paying attention to good principles as you go along works out pretty well.

blocks|key|355760|text|我考虑以下几点：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|355761|355762|系统应该做什么，也就是说，系统试图解决的问题是什么，客户是谁，他们的愿望是什么，以及系统必须与|ordered-list-item|355763|集成在一起。是否有任何遗留方面需要进行集成:+the+user+considered|355764|what|355765|355766|然后我开始把系统看作一个黑匣子，然后：|355767|355768|需要与该黑盒进行哪些交互|355769|需要在黑盒内部进行哪些行为，即需要对这些交互进行哪些处理才能使黑盒在更高级别上表现出所需的行为，例如接收和处理来自预订系统的传入消息、更新数据库等。|355770|355771|然后，这将开始为您提供一个由各种内部黑盒组成的系统视图，每个黑盒都可以以相同的方式进一步分解。|355772|UML很好地表示了这样的行为。您可以只使用UML众多组件中的两个来描述大多数系统，即：|355773|355774|类图和|unordered-list-item|355775|序列图。|355776|355777|如果需要描述的行为中存在任何并行性，您可能还需要活动图。|355778|学习统一建模语言的一个很好的资源是Martin+Fowler的一本优秀的书"UML+Distilled“(Amazon+link+-+sanitised+for+the+script+script+link+nazis+out+(-：)+)。本书将让您快速了解UML的每个组件的基本部分。|offset|length|355779|噢。我所描述的几乎就是Ivar+Jacobson的方法。雅各布森是面向对象的三个朋友之一。事实上，UML最初是由另外两个人开发的，他们组成了三个朋友Grady+Booch和Jim+Rumbaugh。|355780|entityMap|0|LINK|mutability|MUTABLE|url|https://rads.stackoverflow.com/amzn/click/com/0321193687^0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|1H|B|0|0|0^^$0|@$1|2|3|4|5|6|7|1J|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|1K|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|1L|8|@]|9|@]|A|$]]|$1|F|3|G|5|E|7|1M|8|@]|9|@]|A|$]]|$1|H|3|I|5|E|7|1N|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|1O|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|1P|8|@]|9|@]|A|$]]|$1|M|3|-4|5|6|7|1Q|8|@]|9|@]|A|$]]|$1|N|3|O|5|E|7|1R|8|@]|9|@]|A|$]]|$1|P|3|Q|5|E|7|1S|8|@]|9|@]|A|$]]|$1|R|3|-4|5|6|7|1T|8|@]|9|@]|A|$]]|$1|S|3|T|5|6|7|1U|8|@]|9|@]|A|$]]|$1|U|3|V|5|6|7|1V|8|@]|9|@]|A|$]]|$1|W|3|-4|5|6|7|1W|8|@]|9|@]|A|$]]|$1|X|3|Y|5|Z|7|1X|8|@]|9|@]|A|$]]|$1|10|3|11|5|Z|7|1Y|8|@]|9|@]|A|$]]|$1|12|3|-4|5|6|7|1Z|8|@]|9|@]|A|$]]|$1|13|3|14|5|6|7|20|8|@]|9|@]|A|$]]|$1|15|3|16|5|6|7|21|8|@]|9|@$17|22|18|23|1|24]]|A|$]]|$1|19|3|1A|5|6|7|25|8|@]|9|@]|A|$]]|$1|1B|3|-4|5|6|7|26|8|@]|9|@]|A|$]]]|1C|$1D|$5|1E|1F|1G|A|$1H|1I]]]]

I consider the following:

<ol>
<li>what the system is supposed to do, that is, what is the problem that the system is trying to solve</li>
<li>who is the customer and what are their wishes</li>
<li>what the system has to integrate with</li>
<li>are there any legacy aspects that need to be considered</li>
<li>what are the user interractions</li>
<li>etc...</li>
</ol>

Then I start looking at the system as a black box and:

<ol>
<li>what are the interactions that need to happen with that black box</li>
<li>what are the behaviours that need to happen inside the black box, i.e. what needs to happen to those interactions for the black box to exhibit the desired behaviour at a higher level, e.g. receive and process incoming messages from a reservation system, update a database etc.</li>
</ol>

Then this will start to give you a view of the system that consists of various internal black boxes, each of which can be broken down further in the same manner.

UML is very good to represent such behaviour. You can describe most systems just using two of the many components of UML, namely:

<ul>
<li>class diagrams, and</li>
<li>sequence diagrams.</li>
</ul>

You may need activity diagrams as well if there is any parallelism in the behaviour that needs to be described.

A good resource for learning UML is Martin Fowler's excellent book "UML Distilled" (<a href="https://rads.stackoverflow.com/amzn/click/com/0321193687" rel="noreferrer" rel="nofollow noreferrer">Amazon link</a> - sanitised for the script kiddie link nazis out there (-: ). This book gives you a quick look at the essential parts of each of the components of UML.

Oh. What I've described is pretty much Ivar Jacobson's approach. Jacobson is one of the Three Amigos of OO. In fact UML was initially developed by the other two persons that form the Three Amigos, Grady Booch and Jim Rumbaugh

blocks|key|3143435|text|我不相信任何事情都可以在实施之前提前计划好。我有10年的经验，但只有4家公司(包括一家公司的2个网站，几乎是两极对立的)，而且我几乎所有的经验都是在观察巨大的集群发生方面。我开始认为像重构这样的东西确实是做事情的最好方法，但同时我意识到我的经验是有限的，我可能只是对我所看到的做出反应。我真正想知道的是如何获得最好的经验，这样我才能得出正确的结论，但似乎没有捷径，只是需要花很多时间看到人们做错了事情：我真的很想尝试在一家公司工作，在那里人们做正确的事情(成功的产品部署证明了这一点)，知道我是否只是一个逆向投资的混蛋，或者我是否真的像我认为的那样聪明|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3143436|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I'm not convinced anything can be planned in advance before implementation. I've got 10 years experience, but that's only been at 4 companies (including 2 sites at one company, that were almost polar opposites), and almost all of my experience has been in terms of watching colossal cluster********s occur. I'm starting to think that stuff like refactoring is really the best way to do things, but at the same time I realize that my experience is limited, and I might just be reacting to what I've seen. What I'd really like to know is how to gain the best experience so I'm able to arrive at proper conclusions, but it seems like there's no shortcut and it just involves a lot of time seeing people doing things wrong :(. I'd really like to give a go at working at a company where people do things right (as evidenced by successful product deployments), to know whether I'm a just a contrarian bastard, or if I'm really as smart as I think I am.

blocks|key|3143501|text|我不同意:+UML可以用于应用程序架构，但更多地用于技术架构(框架、类或序列图等)，因为这是那些图最容易与开发保持同步的地方。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3143502|当您采用一些功能规范(描述操作的性质和流程，而不对未来的实现做出任何假设)，并将其转换为技术规范时，就会发生。|3143503|这些规范代表了实现某些业务和功能需求所需的应用程序。|offset|length|style|BOLD|3143504|因此，如果您需要处理几个大型金融投资组合(功能规范)，您可能会确定需要将该大型规范划分为：|3143505|3143506|a+dispatcher将这些繁重的计算分配给不同的服务器|unordered-list-item|3143507|a+launcher以确保所有计算服务器在开始处理这些项目组合之前都已启动并运行。|3143508|一个图形用户界面以能够显示正在发生的事情。|3143509|是一个“通用”组件，用于开发特定的项目组合算法，独立于应用程序体系结构的其余部分，以便促进单元测试以及一些功能和回归测试。|3143510|3143511|因此，基本上，考虑应用程序架构就是决定您需要以一致的方式开发什么“文件组”(您不能在同一组文件中开发启动器、图形用户界面、分派器……：它们不能以相同的速度发展)。|3143512|当应用程序体系结构定义良好时，它每个组件通常都是配置组件的一个很好的候选者，配置组件是一组文件，可以作为一个版本控制系统(+VCS+)，这意味着每次需要记录应用程序的快照时，它的所有文件都将被标记在一起(同样，很难标记所有系统，它的每个应用程序不可能同时处于稳定状态)|3143513|entityMap^0|0|0|L|4|0|0|0|0|0|0|0|0|9|6|0|0^^$0|@$1|2|3|4|5|6|7|12|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|13|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|14|8|@$F|15|G|16|H|I]]|9|@]|A|$]]|$1|J|3|K|5|6|7|17|8|@]|9|@]|A|$]]|$1|L|3|-4|5|6|7|18|8|@]|9|@]|A|$]]|$1|M|3|N|5|O|7|19|8|@]|9|@]|A|$]]|$1|P|3|Q|5|O|7|1A|8|@]|9|@]|A|$]]|$1|R|3|S|5|O|7|1B|8|@]|9|@]|A|$]]|$1|T|3|U|5|O|7|1C|8|@]|9|@]|A|$]]|$1|V|3|-4|5|6|7|1D|8|@]|9|@]|A|$]]|$1|W|3|X|5|6|7|1E|8|@$F|1F|G|1G|H|I]]|9|@]|A|$]]|$1|Y|3|Z|5|6|7|1H|8|@]|9|@]|A|$]]|$1|10|3|-4|5|6|7|1I|8|@]|9|@]|A|$]]]|11|$]]

I beg to differ: UML can be used for application architecture, but is more often used for technical architecture (frameworks, class or sequence diagrams, ...), because this is where those diagrams can most easily been kept in sync with the development.

<a href="https://stackoverflow.com/questions/212270#212362">Application Architecture</a> occurs when you take some functional specifications (which describe the nature and flows of operations without making any assumptions about a future implementation), and you transform them into technical specifications.

Those specifications represent the applications you need for implementing some business and functional needs.

So if you need to process several large financial portfolios (functional specification), you may determine that you need to divide that large specification into:

<ul>
<li>a dispatcher to assign those heavy calculations to different servers</li>
<li>a launcher to make sure all calculation servers are up and running before starting to process those portfolios.</li>
<li>a GUI to be able to show what is going on.</li>
<li>a "common" component to develop the specific portfolio algorithms, independently of the rest of the application architecture, in order to facilitate unit testing, but also some functional and regression testing.</li>
</ul>

So basically, to think about application architecture is to decide what "group of files" you need to develop in a coherent way (you can not develop in the same group of files a launcher, a GUI, a dispatcher, ...: they would not be able to evolve at the same pace)

When an application architecture is well defined, each of its components is usually a good candidate for a configuration component, that is a group of file which can be versionned as a all into a VCS (Version Control System), meaning all its files will be labeled together every time you need to record a snapshot of that application (again, it would be hard to label all your system, each of its application can not be in a stable state at the same time)

blocks|key|3356416|text|你绝对应该看看Steve+McConnell的Code+Complete-+-尤其是他关于“构建中的设计”的免费章节。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3356417|你可以从他的网站上下载：|3356418|http://cc2e.com/File.ashx?cid=336|offset|length|3356419|entityMap|0|LINK|mutability|MUTABLE|url^0|0|0|0|X|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|P|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|Q|8|@]|9|@$F|R|G|S|1|T]]|A|$]]|$1|H|3|-4|5|6|7|U|8|@]|9|@]|A|$]]]|I|$J|$5|K|L|M|A|$N|E]]]]

You should definitely take a look at Steve McConnell's Code Complete-
and especially at his giveaway chapter on "Design in Construction"

You can download it from his website:

<a href="http://cc2e.com/File.ashx?cid=336" rel="noreferrer">http://cc2e.com/File.ashx?cid=336</a>

blocks|key|360569|text|我试图将我的想法分成两个方面:我试图操纵的事物的表示，以及我打算如何处理它们。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|360570|当我试图对我试图操纵的东西进行建模时，我想出了一系列离散的项目定义-一个电子商务网站将有一个SKU，一个产品，一个客户，等等。我也会有一些我正在处理的非物质的东西--一个订单，或者一个类别。一旦我在系统中有了所有的“名词”，我将创建一个域模型来显示这些对象是如何相互关联的--一个订单有一个客户和多个SKUs，许多skus被分组到一个产品中，等等。|360571|这些域模型可以表示为UML域模型、类图和SQL+ERD。|360572|一旦我弄清楚了系统的名词，我就转到动词-例如，这些项目中的每一个都要执行的操作来提交订单。这些通常很好地映射到我的功能需求中的用例--我找到的表达这些用例的最简单的方法是UML序列图、活动图、协作图或泳道图。|360573|重要的是要把这看作是一个迭代过程；我将在域中做一小段时间，然后处理操作，然后再返回。理想情况下，我会有时间写代码来尝试我正在进行的事情-你永远不会希望设计在应用程序之前走得太远。如果您认为您正在构建所有东西的完整和最终架构，那么这个过程通常是可怕的；实际上，您所要做的只是建立团队在开发过程中将共享的基本基础。你主要是在为团队成员创建一个共享的词汇表，供他们在描述系统时使用，而不是制定如何完成它的规则。|360574|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|N|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|O|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|P|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|K|$]]

I try to break my thinking down into two areas: a representation of the things I'm trying to manipulate, and what I intend to do with them.

When I'm trying to model the stuff I'm trying to manipulate, I come up with a series of discrete item definitions- an ecommerce site will have a SKU, a product, a customer, and so forth. I'll also have some non-material things that I'm working with- an order, or a category. Once I have all of the "nouns" in the system, I'll make a domain model that shows how these objects are related to each other- an order has a customer and multiple SKUs, many skus are grouped into a product, and so on.

These domain models can be represented as UML domain models, class diagrams, and SQL ERD's.

Once I have the nouns of the system figured out, I move on to the verbs- for instance, the operations that each of these items go through to commit an order. These usually map pretty well to use cases from my functional requirements- the easiest way to express these that I've found is UML sequence, activity, or collaboration diagrams or swimlane diagrams.

It's important to think of this as an iterative process; I'll do a little corner of the domain, and then work on the actions, and then go back. Ideally I'll have time to write code to try stuff out as I'm going along- you never want the design to get too far ahead of the application. This process is usually terrible if you think that you are building the complete and final architecture for everything; really, all you're trying to do is establish the basic foundations that the team will be sharing in common as they move through development. You're mostly creating a shared vocabulary for team members to use as they describe the system, not laying down the law for how it's gotta be done.

blocks|key|3143676|text|我还不够聪明，不能提前做好计划。当我提前做计划时，我的计划总是会出错，但现在我已经花了n天在糟糕的计划上。在白板上，我的限制似乎是15分钟。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3143677|基本上，我会做尽可能少的工作来确定我是否在朝着正确的方向前进。|3143678|我看着我的设计中的关键问题:当A从B到C时，它对D来说是否足够快？如果不是，我们需要一个不同的设计。每一个问题都可以用一个尖峰来回答。如果峰值看起来不错，那么我们就有了设计，是时候扩展它了。|3143679|我的目标是尽快获得一些真正的客户价值，这样客户就可以告诉我应该去哪里。|3143680|因为我总是把事情搞错，所以我依靠重构来帮助我把事情做好。重构是有风险的，所以我不得不边走边写单元测试。由于耦合的原因，事后编写单元测试很困难，所以我先写测试。保持对这些东西的纪律性是很难的，而且不同的大脑会有不同的看法，所以我喜欢有一个伙伴和我一起编码。我的编程伙伴有个鼻子，所以我经常洗澡。|3143681|让我们称之为“极限编程”。|3143682|entityMap^0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|P|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|Q|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|R|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|S|8|@]|9|@]|A|$]]|$1|L|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|M|$]]

I'm not smart enough to plan ahead more than a little. When I do plan ahead, my plans always come out wrong, but now I've spend n days on bad plans. My limit seems to be about 15 minutes on the whiteboard.

Basically, I do as little work as I can to find out whether I'm headed in the right direction.

I look at my design for critical questions: when A does B to C, will it be fast enough for D? If not, we need a different design. Each of these questions can be answer with a spike. If the spikes look good, then we have the design and it's time to expand on it.

I code in the direction of getting some real customer value as soon as possible, so a customer can tell me where I should be going.

Because I always get things wrong, I rely on refactoring to help me get them right. Refactoring is risky, so I have to write unit tests as I go. Writing unit tests after the fact is hard because of coupling, so I write my tests first. Staying disciplined about this stuff is hard, and a different brain sees things differently, so I like to have a buddy coding with me. My coding buddy has a nose, so I shower regularly.

Let's call it "Extreme Programming".

blocks|key|357939|text|我发现自己在编码之前很难完全考虑出一个系统。仅仅粗略地浏览一下某些组件是太容易了，因为你后来才意识到它们比你想象的要复杂得多。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|357940|一种解决方案就是努力尝试。在任何地方编写UML。每节课都要看一遍。想一想它将如何与其他类交互。这很难做到。|357941|我喜欢做的是首先做一个概括性的概述。我不喜欢UML，但我喜欢用图表来表达我的观点。然后我开始实施它。即使我只是写出带有空方法的类结构，我也经常看到之前遗漏的东西，所以我更新了我的设计。当我编写代码时，我会意识到我需要做一些不同的事情，所以我会更新我的设计。这是一个迭代过程。“首先设计所有东西，然后实现所有东西”的概念被称为瀑布模型，我认为其他人已经证明这是一种糟糕的软件开发方式。|offset|length|style|BOLD|357942|entityMap^0|0|0|3O|4|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|N|8|@$F|O|G|P|H|I]]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|K|$]]

I find myself having trouble fully thinking a system out before coding it. It's just too easy to only bring a cursory glance to some components which you only later realize are much more complicated than you thought they were.

One solution is to just try really hard. Write UML everywhere. Go through every class. Think how it will interact with your other classes. This is difficult to do.

What I like doing is to make a general overview at first. I don't like UML, but I do like drawing diagrams which get the point across. Then I begin to implement it. Even while I'm just writing out the class structure with empty methods, I often see things that I missed earlier, so then I update my design. As I'm coding, I'll realize I need to do something differently, so I'll update my design. It's an iterative process. The concept of "design everything first, and then implement it all" is known as the waterfall model, and I think others have shown it's a bad way of doing software.

blocks|key|357944|text|试试阿基米特。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|357945|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

blocks|key|355933|text|“白板、草图和便利贴都是很好的设计工具。复杂的建模工具往往更容易让人分心，而不是启发人。”来自Practices+of+an+Agile+Developer+by+Venkat+Subramaniam+and+Andy+Hunt。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|355934|entityMap|0|LINK|mutability|MUTABLE|url|http://www.pragprog.com/titles/pad/practices-of-an-agile-developer^0|1B|1V|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

"White boards, sketches and Post-it notes are excellent design
tools. Complicated modeling tools have a tendency to be more
distracting than illuminating." From <a href="http://www.pragprog.com/titles/pad/practices-of-an-agile-developer" rel="nofollow noreferrer">Practices of an Agile Developer
by Venkat Subramaniam and Andy Hunt</a>.

blocks|key|3356618|text|我从事建筑工作已经有一段时间了。我首先使用BPML改进业务流程，然后使用UML捕获各种细节！第三步通常是ERD！当您使用完BPML和UML时，您的ERD将会相当稳定！没有计划是完美的，也没有抽象是100%25的。计划重构，目标是尽可能减少重构！|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3356619|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I have been doing architecture for a while. I use BPML to first refine the business process and then use UML to capture various details! Third step generally is ERD! By the time you are done with BPML and UML your ERD will be fairly stable! No plan is perfect and no abstraction is going to be 100%. Plan on refactoring, goal is to minimize refactoring as much as possible!

One thing I struggle with is planning an application's architecture before writing any code.

I don't mean gathering requirements to narrow in on what the application needs to do, but rather effectively thinking about a good way to lay out the overall class, data and flow structures, and iterating those thoughts so that I have a credible plan of action in mind before even opening the IDE. At the moment it is all to easy to just open the IDE, create a blank project, start writing bits and bobs and let the design 'grow out' from there.

I gather UML is one way to do this but I have no experience with it so it seems kind of nebulous.

How do you plan an application's architecture before writing any code? If UML is the way to go, can you recommend a concise and practical introduction for a developer of smallish applications?

I appreciate your input.

How do you plan an application's architecture before writing any code?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我正在努力解决的一件事是在编写任何代码之前规划应用程序的架构。我的意思不是收集需求来缩小应用程序需要做的范围，而是有效地考虑一种好的方法来布局整个类、数据和流结构，并迭代这些想法，以便在打开IDE之前就有一个可靠的行动计划。目前，只需打开IDE，创建一个空白项目，开始编写一些小代码，然后让设计从那里“成长”出来，这一切...

问在编写任何代码之前，如何规划应用程序的体系结构？
EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问在编写任何代码之前，如何规划应用程序的体系结构？EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问在编写任何代码之前，如何规划应用程序的体系结构？
EN