领域建模
分析的另一种重要产品是领域模型，其目标是使负责该系统基本行为的所有核心类可视。
软件的核心是它为用户解决领域相关问题的能力。
模型的选择会影响最终产生的系统的灵活性和可重用性。
由内而外早就软件。忽视了领域模型这个“内”，而仅重视编写程序这个“外”，多半是要出问题的。在对象开发过程中一个很重要的原则就是：要设计软件，使得软件的结构反映问题的结构。模型的选择会影响最终产生的系统的灵活性和可重用性。领域模型是对实际问题领域的抽象表示，它专注于分析问题领域本身，发掘重要的业务领域概念，并建立业务领域概念之间的关系。类图无疑是领域模型中使用最多的UML图，但有时状态图可以用来对业务领域对象的状态变化进行有效的补充说明。领域建模是公认的促使OO项目成功的最佳实践之一。
需求分析的两个困难：
1、 用户的参与不够，造成需求分析成果中假设的成分太多；
2、 问题领域太复杂时，需求分析的开展会遇到困难。
为解决上述两个困难，除了运用原型等方法进行需求启发之外，我们还有必要和用户进行“更一级”的沟通。领域模型是对实际问题领域的抽象，它“穿透”用户想要的功能表象，专注于分析问题领域本身，发掘重要的业务领域概念，并建立业务领域概念之间的关系。因此，开发方和用户在“领域模型”上达成的共识，往往比在“功能需求”上达成的共识“更深一级”，从而也更加稳固。“用户参与不够”其实是两个问题：用户参与不够多，或者用户参与不够深入。（笔者同意上述观点，但与用户在领域模型上达成共识，可谓可遇不可求，因为这需要用户在有一定的技术背景，并且是很资深的业务专家，因为领域模型毕竟已经是一种抽象）。用户代表或领域专家深入参与领域建模活动，可以避免需求分析员对业务领域的理解一直停留在假设的层面，直到软件开发出来后才被用户发现的尴尬局面出现。另外，领域建模对需求分析起着必要的支持作用。
领域模型是探索问题领域的工具，可以帮助我们探索和提炼问题领域知识。领域建模和需求分析活动是相互伴随、相互支持的。领域建模提供的词汇表应当成为所有团队成员所使用语言的核心，在需求活动以及其他活动中起到与团队交流基础的作用。另一方面，需求捕获和分析非常关键，因为不知道客户想要什么，就无法提供让客户满意的软件。
领域模型为需求定义提供了领域知识和领域词汇。软件界面的设计往往和领域模型关系密切，领域信息是所要展现内容中最重要的部分，界面结构必须和业务内容的结构相一致。领域模型是否合理将严重影响软件系统的可扩展性，模型的选择会影响最终产生的系统的灵活性和可重用性。领域模型经过精化之后会成为业务层的核心。领域模型是设计持久化数据模型的良好基础，在实践中直接将领域模型映射成物理数据模型的例子也屡见不鲜。（在笔者的经验中，如果项目中使用了全自动的ORMapping框架，如Hibernate，那么直接将领域模型映射为物理数据模型，是方便的。但如果是使用半自动的ORMapping框架，如iBatis，或纯手工的JDBC或Spring的JDBC Template，那么还是需要在领域模型与物理数据模型之间多引入一个数据对象，由其隔离物理数据模型的变更对领域模型的冲击）
《人月神话》一书指出了软件开发的“根本问题”，首当其冲的就是“软件的复杂性”。而运用面向对象的领域模型技术，可以帮助我们减轻复杂性的问题。领域模型本身将注意力始终保持在最为重要的业务概念及其关系上，使我们能够不断深入地、系统地整理对问题的认识。领域建模活动的结果是领域模型，但是由于问题领域的复杂性，领域模型不是一蹴而就的。在领域建模过程中，前期的成果往往很不完善，我们会不断基于现有的成果进行讨论、分析和完善。因此，领域建模的过程就是探索复杂问题的过程，而领域模型的早期版本本身也成了促进进一步思维的工具。领域模型决定了软件系统功能的范围。任何模型都是对现实世界的某种程度的抽象，领域模型也不例外。抽象意味着有目的性地忽略；而忽略哪些对象关系，保留哪些对象和关系，都和具体目的有关。领域模型还影响着软件系统的可扩展性。功能是软件系统能够完成的具体任务；而模型揭示了丰富多彩的功能需求背后的结构，是我们设法“驯服”复杂性时有了切中要害的“着力点”。功能需求记录了系统外在的、用户可感知的“应用列表”，但它们是易变的，当商业环境急剧变化的时候需求尤其易变；而领域模型揭示并模拟问题领域的内部结构，相当于对问题领域进行了一层抽象，良好的领域模型不仅支持现有功能需求的满足，还在一定程度上支持未来可能出现的新需求。
团队开发最重要的问题有三个：交流、交流，还是交流。而领域模型是团队交流的基础，是所有团队成员所使用语言的核心。领域模型规定了重要的领域词汇表，并且这些词汇的定义是严格的、大家共同认可的，所以可以成为团队交流的基础。
确定对软件架构关键的需求
功能、质量和商业需求的某个集合“塑造”了架构。我们把这些塑造需求称为“架构驱动因素”。我们的策略是：在架构设计期间，关键需求决定架构，其余需求验证架构。“关键需求决定架构”和“全面认识需求”的策略是不矛盾的。
架构并不是静态的功能，因此无法优化至最佳——无论是设计约束，还是棘手问题，都不会长时间不变而“等”你找到最佳方案。架构不是要完美，而是要足够满意。
把所有需求统统确定下来之后再开始下游活动是不现实的。需求来自于实践的需要，而实践是发展的，所以“确定的需求”只能是暂时的。另外，项目何时交付往往是有客户业务的需要决定的，或者是由市场形势决定的，这使得项目工期成了不可改变的“外部限制”。所以，我们需要将有限的精力投入到深入分析最为重要的需求。因为需求是“促成设计决策的因素”，因此需求的变更可能会引起架构设计不再适合。无论对于概念性架构的设计还是实际架构的设计，都需要对关键用例进行分析。回到软件架构的定义，所谓软件架构就是关于如何构建软件的一些最重要的设计决策，这些决策往往是围绕将系统分为哪些部分、各部分之间如何交互展开的。要达到高质量属性的要求，是有成本的。例如，持续可用性的成本最为明显，它往往要求通过硬件及网络链接的冗余来实现，使成本投入非常客观。商业需求指“组织或客户高层次的目标”。但作为“架构设计驱动因素”的商业需求有着更宽泛的含义：它关注从客户群、企业现状、未来发展、预算、立项、开发、运营、维护在内的整个软件生命周期涉及的商业因素，包括了商业层面的目标、期望和限制等。
概念性架构设计
功能、质量和商业需求的某个集合塑造了架构。软件系统的概念性架构设计旨在规划关键问题的解决策略。
概念性架构设计的关键步骤：
1、 鲁棒性分析：通过分析用例规约中的事件流，识别出实际用例规约的功能所需的主要对象及其职责，形成以职责为主的初步设计。
2、 引入架构模式：架构模式也称为架构风格，是软件界长期实践的经验结晶。架构模型的核心是架构机制，即以“架构模型=组件+连接器”的形式明确关键设计元素和关键交互方式。
3、 质量属性分享：质量属性分析给软件架构师提供了明确的机会去思考和解决这一问题，有利于提升软件设计质量。
鲁棒性分析产生的职责模型是引入架构模式、进行质量属性分析的基础，并在这一过程中被调整、被细化，也被组织得更有规律。引入架构模式是为了确定关键的交互机制，而质量属性分析将针对质量需求制定相关设计决策。
从用例规约向设计概念过渡之所以困难是因为，第一，用例是面向问题域的，设计是面向机器域的，这两个“空间”之间存在映射；第二，用例技术本身不是面向对象的，而设计应该是面向对象的，这是两种不同的思维方式；第三，用例规约采用自然语言描述，而设计采用形式化的模型描述。
边界对象对模拟外部环境和未来系统之间的交互进行建模。控制对象对行为进行封装，描述用例中事件流的控制行为。实体对象对需要存储的信息进行描述，它往往来自领域概念，和领域模型中的对象有良好的对应关系。
对象的三类职责：交互、控制、信息。就面向对象系统而言，一个场景的“产生”是一连串的对象协作的“结果”，通过分析场景可以发现这些对象。模型关注职责的划分，而无论是交互、控制，还是信息维度的职责，都是和具体实现技术这一维是独立的（或者称正交的）。
所谓软件架构就是关于如何构建软件的一些最重要的设计决策，这些决策往往是围绕将系统分为哪些部分、各部分之间如何交互展开的。架构模式描述了软件系统基本的结构化组织方案。具体而言，架构模式提供了一套预定义的子系统，并规定了子系统的职责，以及子系统间关系的组织原装和组织指南。分层架构的最大优点是将整体问题局部化，把可能的变化分别封装在不同的层中，系统被规划为一个单向依赖的分层体现，利于修改、扩展和替换。如果说任何一种架构模式都关注职责划分和交互机制这两方面的话，那么我们常说的“分层架构”往往只关注职责划分。微内核架构“生来”就是为了适应变化的。为此，微内核架构不仅将应用相关部分与通用部分分离，而且又将通过部分进一步分离成一个最小化的基本服务内核和众多扩展内核。
概念性架构应该为系统的关键设计目标负责，对规模很大的软件系统非常有意义。
质量属性分析
忽略包括质量属性需求在内的非功能需求是很要命的。
软件质量属性可以分为运行期质量属性和开发期质量属性两大类。各类需求对架构设计的影响不同，不同质量属性对架构也要求各异。众多质量属性需求之间往往会有冲突，我们必须权衡。质量属性分析是概念性架构设计的重要步骤。概念性架构包括一些高层次的设计选择，对未来软件系统的质量和功能都起着关键作用。“确定关键需求”活动会甄选出包含关键的功能需求、关键的质量属性要求，以及商业层面的目标和限制在内的一个需求子集。在概念性架构设计时，功能需求是鲁棒性分析最主要的输入，而质量属性需求是质量属性分析的最主要的输入。所谓质量性分析，是软件架构师对软性系统要达到的质量属性需求进行分析、制定相应软件架构设计决策的过程。“属性—场景—决策”方法提倡通过一组具体场景将要达到的质量属性需求目标细化。
“可测试的需求”是发展方向。“将质量属性需求细化为一组质量场景”这一方法，发现实施它的最佳时机是需求分析期间，而不是架构设计之时——即《需求文档》应将质量属性需求细化到一组具体的场景。
