架构设计实践一:架构设计过程

节奏

做好架构设计需要做到看透需求、架构大方向正确、设计好架构的各个方面。

  • 看透需求要求既要把需求找全,也要把需求项之间的矛盾关系、追溯关系搞清楚。需求找全可使用二维需求矩阵,从业务级、用户级、开发级和广义功能、质量、约束两个维度来找。一个矛盾关系的例子是安全性和互操作性的矛盾;一个追溯关系的例子是需求范围与系统目标的关系。
  • 架构大方向正确是指要做好概念架构设计,概念架构重视“找对路子”,关注做好架构模式选型、集成技术选型等,不关注明确的接口定义。产品彩页上印的架构、售前提到的架构、投标使用的架构均是概念架构。关键需求决定概念架构。
  • 使用多视图方法来设计好架构的各个方面。

步骤

  • 需求分析:全面认识需求并权衡不同需求之间的相互关系
  • 领域建模:透过问题域的现象,捕捉其背后最为稳定领域概念及这些概念之间的关系。领域模型是团队各成员之间交流的语言核心,领域模型需要随着项目的进展而不断精化。
  • 确定关键需求:注意包括功能性需求和非功能性需求。
  • 概念架构设计:(1)如何划分顶层子系统;(2)架构风格选型;(3)开发技术选型;(4)集成技术选型;(5)二次开发技术选型
  • 细化架构设计:小系统使用逻辑架构+物理架构,大系统使用逻辑架构+开发架构+物理架构+运行架构+数据架构。
  • 架构验证:不仅仅需要评审,重要系统还需开发出架构原型,使用可运行的程序来验证架构。
时间: 2024-08-10 11:59:33

架构设计实践一:架构设计过程的相关文章

【DDD】领域驱动设计实践 —— 架构风格及架构实例

概述 DDD为复杂软件的设计提供了指导思想,其将易发生变化的业务核心域放置在限定上下文中,在确保核心域一致性和内聚性的基础上,DDD可以被多种语言和多种技术框架实现,具体的框架实现需要根据实际的业务场景和需求来制定. 核心的指导思路归纳为: 关注点放在domain上,将业务领域限定在同一上下文中 降低上下文之间的依赖,通过‘开发主机服务’(REST服务是其中的一种).‘消息模式’.‘事件驱动’等架构风格实现 遵循分层架构模式 架构风格 针对DDD的架构设计,<实现领域驱动设计>提到了几种架构风

朱晔的互联网架构实践心得S1E9:架构评审一百问和设计文档五要素

朱晔的互联网架构实践心得S1E9:架构评审一百问和设计文档五要素 [下载文本PDF进行阅读] 本文我会来说说我认为架构评审中应该看的一些点,以及我写设计文档的一些心得.助你在架构评审中过五关斩六将,助你写出能让人收藏点赞的设计文档. 技术架构评审 架构评审或技术方案评审的价值在于集众人的力量大家一起来分析看看方案里是否有坑,方案上线后是否会遇到不可逾越的重大技术问题,提前尽可能把一些事情先考虑到提出质疑其实对项目的健康发展有很大的好处.很多公司都有架构评审委员会都有架构评审的流程,做业务的兄弟要

架构设计实践二:需求分析

1.1 三个问题 掌握好需求分析,需要掌握三个问题的解决方式. 需求如何获得?需求开发=愿景分析+需求分析 如何判断需求全不全?功能.质量.约束三类需求 如何从需求转换为设计?功能.质量.约束对架构产生不同的影响. 1.2 软件研发与交付过程总图 其中概念化阶段一般都要完成愿景分析.风险评估.可行性分析及项目进度和成本的粗略估算,输出<愿景与范围文档>:需求分析阶段则完成需求捕获.需求分析,得到<软件需求规格说明书>,一个关键的思路是需求捕获与需求分析是迭代着进行的,完成需求捕获之

架构的坑系列:重构过程中的过度设计

架构的坑系列:重构过程中的过度设计 软件架构   2016-06-03 08:47:02 发布 您的评价:       5.0   收藏     2收藏 这个系列是 坑 系列,会说一些在系统设计,系统架构上的 坑 ,这些都是我想到哪说到哪,有像这篇一样比较宏观的 坑 ,后面的文章也会有到具体技术细节的(比如某个函数,某个系统调用) 坑 ,总之,到处都是坑,这些坑有些是我经历过的,有些是听说的,你也可以留言说说你遇到的 坑 . 这一篇,我们从 重构 这个场景来看看系统架构的设计中 过度设计 这个坑

阿里P8级架构师浅析秒杀架构设计实践思路

一.前言 一提到秒杀,都会想到高性能.高并发.高可用.大流量-.在电商体系中,交易系统占据了环节中的半壁江山.比如里面特别迷人的秒杀系统,那秒杀涉及到什么架构设计?会涉及到什么业务? 泥瓦匠自言自语:秒杀这个东西,一篇文章也说不完.我这一篇起个头,实践系列还在后面,敬请期待. 二.秒杀业务难点 秒杀业务难点,总结为两点 并发多读 并发少写 这不同于一些场景,优惠营销系统,只会是一个用户读多个数据,但也会大流量的读操作.但没有啥写操作. 并发多读,多用户并发读一个数据.比如华为手机只有一个库存,活

阿里游戏高可用架构设计实践

今天读了李云华老师写的<阿里游戏高可用架构设计实践 >,有一些感受想分享一下. 印象很深的一句话那就是他最开始说的“把韵味的锅让研发去背!”也就是说,高可用的系统是设计出来的,不是靠运维保障出来的! 他提到出现问题人们的思考顺序为:首先想到的是不是运维太LOW了,比如说硬件质量太差,为什么这个月机柜也坏.交换机也坏,是不是到电脑城买个二手货放里面了?第二想到的是不是运气不好,之前一个月.两个月才遇到一次,这个月遇到了4次,是不是你们没有在机房烧香?第三个是不是测试不足,为什么这些Bug测试阶段

SOA架构设计经验分享—架构、职责、数据一致性

阅读目录: 1.背景介绍 2.SOA的架构层次 2.1.应用服务(原子服务) 2.2.组合服务 2.3.业务服务(编排服务) 3.SOA化的重构 3.1.保留服务空间,为了将来服务的组合 4.运用DDD+GRASP进行分析和设计(防止主观的判断导致错误的假设) 5.SOA分布式下的数据一致性 5.1.分布式事务(基于DTC的分布式事务) 5.2.事务补偿(提供正向或反向的操作来让数据在业务上是一致的) 5.3.异步EDA(基于异步事件流来实现柔性的分布式事务) 6.总结 1.背景介绍 最近一段时

[转]SOA架构设计经验分享&mdash;架构、职责、数据一致性

阅读目录: 1.背景介绍 2.SOA的架构层次 2.1.应用服务(原子服务) 2.2.组合服务 2.3.业务服务(编排服务) 3.SOA化的重构 3.1.保留服务空间,为了将来服务的组合 4.运用DDD+GRASP进行分析和设计(防止主观的判断导致错误的假设) 5.SOA分布式下的数据一致性 5.1.分布式事务(基于DTC的分布式事务) 5.2.事务补偿(提供正向或反向的操作来让数据在业务上是一致的) 5.3.异步EDA(基于异步事件流来实现柔性的分布式事务) 6.总结 1.背景介绍 最近一段时

云舒网络:容器系列二:容器的视角-设计交付和架构

前言: 我们要使用容器,自然就不能回避容器的设计生成过程,而生成之后就涉及到加载运行和管理,那么今天我们就从设计交付和架构这两个角度来说一下容器. 注:本期分享由代豪原创,云舒网络整理发布. 上篇的<容器起源>说了容器是什么,那么这次我们从两个视角谈谈容器.我们要使用容器,自然就不能回避容器的设计生成过程,而生成之后就涉及到加载运行和管理,那么今天我们就从设计交付和架构这两个角度来说一下容器.(注:由于目前容器中Docker应用比较广泛,以下内容中的容器默认为Docker.) 一.     设