系统架构39问

系统架构39问

架构视角面面观

架构一个系统不是一件简单的事,需要考虑到的事情也特别的多。下面我列举一些常见的问题,以抛砖引玉。

  1. 是否在不断的学习新技术、新名词、生怕落伍?(WCF、WF、WPF、MVC、EF、WebApi、Spring、Castle、Unity、Autofac、NInject、AOP等)
  2. UI层代码平均是多少行?(WEBForm页面、Winform等页面)
  3. 业务层代码量平均是多少?
  4. 数据访问层代码量平均是多少?
  5. 存储过程、SQL、触发器的代码量是多少?
  6. 系统中有多少配置文件,配置文件的行数是多少?繁多的配置能否减少吗?是否都很必要呀?
  7. 代码量是否作为项目的考核指标?
  8. 项目中的代码是否有很多相似的代码或者冗余的代码?
  9. 项目的业务逻辑分布如何(UI层百分比是多少、业务层百分比是多少、数据访问层百分比是多少、存储过程触发器等百分比是多少)
  10. 开发人员大部分的开发时间是花在什么地方?前段界面、业务逻辑、数据访问层、存储过程、SQL语句、Bug修改。
  11. 开发时间、Bug修复时间的比例是多少?
  12. 开发人员是否经常做自动化单元测试(NUnit、MSUnit等)?
  13. 是否支持AOP扩展(事务处理、权限认证、监控日志等)?
  14. 数据校验怎么处理的?
  15. 是否支持国际化?
  16. 业务逻辑是否可以近乎零配置的方式,发布成WebService、Rest等类型的服务?支持各种终端吗?
  17. UI前端不用改任何代码,只需要简短几行配置把业务逻辑的进程内调用转化为分布式调用吗?
  18. 是否觉得MVC的控制器的代码都很相似,又无法进行很好的重构,如果能和业务逻辑统一起来该多好?
  19. 业务逻辑经过简短配置能否完成从嵌入式部署到分布式部署?并且业务逻辑与分布式部署完全松耦合?并且支持多种协议和数据格式?
  20. 业务逻辑该如何进行垂直分割和水平分割呢?
  21. 是否在为和其它系统的接口对接发愁呢?
  22. 如果页面都是静态化该多好?通过Ajax异步访问领域逻辑多好?
  23. WebPage能像MVC的ViewPage那样支持泛型节约不少代码量的?
  24. WebPage能支持DI注入那该多好?
  25. WebPage能像Mvc那样不用CodeBehind,禁用ViewState,不用任何服务器端控件、UI的响应不通过服务器控件的事件绑 定, 可以自动路由到特定的方法,并且把表单参数和查询字符串的参数以及路由数据自动绑定到Action的方法列表,是不是很期待?
  26. 你的领域逻辑是否被UI前端绑架了?
  27. 你的领域逻辑是否被Asp.net的Session、Cookie、Cache等东东绑架?
  28. 你的领域逻辑是否被MVC或者WebApi的什么什么ActionResult.ControllerContext,ControllerBase,ApiController 等绑架?
  29. 你的领域逻辑是否被WCF的数据契约、服务契约、操作契约以及繁琐的ABC配置所绑架?
  30. 你的领域逻辑是否被WebService、Remoting等分布式架构所绑架?
  31. 你的领域逻辑是否被Ado.net 所绑架(强类型的SqlConnection等)?
  32. 你的领域逻辑是否被ORM所绑架(如EF、NHibernate等)?
  33. 你的领域逻辑是否被不支持多数据库所绑架?
  34. 你的领域逻辑是否很难支持多谢分离?
  35. 没有裸奔的领域逻辑是否该甩掉包袱开始裸奔呢?
  36. 你们的架构是否依赖核心人员?核心人员一旦离职等其它因素脱离该项目,其它人能否玩得转吗?
  37. 你们的架构能否可以做到项目的快速交付和实施吗?
  38. 你们的架构的稳定性、安全性、可扩展性、维护性、易用性如何?
  39. 你们的架构经过简短的培训能够让实习生很快上手吗?

上面的问题,不解决或者都解决对不同岗位的人有什么切身体会呢?

  • 初级软件工程师?
  • 中高级软件工程师?
  • 技术经理?
  • 项目经理?
  • 架构师?
  • 测试工程师?
  • 客户?
  • 领导?

我上面写了30多条个人日常工作中的点滴,但这也只是一个系统架构的一些方面而已。任何系统都是复杂的,我们需要考虑得更加周全,才能做出健壮的系统。

时间: 2024-10-05 12:22:49

系统架构39问的相关文章

系统架构师-基础到企业应用架构-业务逻辑层

一.上章回顾 上章我们主要讲述了系统设计规范与原则中的具体原则与规范及如何实现满足规范的设计,我们也讲述了通过分离功能点的方式来实现,而在软件开发过程中的具 体实现方式简单的分为面向过程与面向对象的开发方式,而目前更多的是面向对象的开发设计方式.并且我们也讲述了该如何通过设计手段去分析功能点及设计分离 点,应该如何在设计的过程中分析的角度及如何去满足设计规范与原则.首先我们通过下图来回顾下上章要点: 二.摘要 本文将已架构的方式去分析分层结构中的业务层的设计,如何写出来内聚度,高耦合的业务逻辑层

系统架构师-基础到企业应用架构-企业应用架构

一.上篇回顾 我们先来回顾下上篇讲解的内容,我们前面的几节分别讲述了,业务逻辑层.数据访问层.服务层.表现层,我们了解了这些分层的职责和分层之间的大概的关联 关系,本篇可能主要是简单的介绍下企业应用的几类模式,结合这几个分层直接的交互来完成系统功能的构建.我们还是先对我们学习的四个分层的职责和功能做个大 概的回顾,我们先来看看下图来回顾下我们讲述的内容. 我想通过上图,大家能回忆起我们讲述的相关内容,然后整理好自己的思路,我们本文将会针对这几个分层进行相应的模式的讲解,并且会结合实例来说明企业应

电商峰值系统架构设计--转载

1.1 系统架构设计目录 摘要:双11来临之际,<程序员>以“电商峰值系统架构设计”为主题,力邀京东.当当.小米.1号店.海尔商城.唯品会.蘑菇街.麦包包等电商企业,及商派.基调网络等服务公司,分享电商峰值系统架构设计的最佳技术实践. 自2009年11月11日,淘宝商城(现名天猫)拉开网购狂欢节的序幕,各大电商的促销浪潮此起彼伏.此时的电商大战不仅是价格之争,更是技术的较量.如何设计电商峰值系统来更好地满足用户蜂拥而至的访问,如何在海量数据处理中实时发现有效信息并转化为商机,成为众多电商企业密

系统架构师-基础到企业应用架构-服务层

一.上章回顾 上篇我们主要讲解了系统架构中的四种架构模式,并且分析了四种架构模式的实现及应用场景,那么先来回顾下架构中的业务逻辑层的使用及总结.  如果大家对图中讲述的内容不明白或者说是不深入那么可以参考上篇讲 解的内容:系统架构师-基础到企业应用架构-业务逻辑层. 二.摘要 本文将已架构的方式去分析分层结构中的服务层的设计,如何设计出来满足我们说的业务需求及设计规范的服务层将是我们的目标,可能我想大家在项目架构的 过程中可能有些同仁,没有用到该层,或者说是采用的是常用的分层结构的设计,而没有把

系统架构师-基础到企业应用架构-数据访问层

一.上章回顾 上篇我们简单讲述了服务层架构模式中的几种,并且讲解了服务层的作用及相关的设计规范,其实我们应该知道,在业务逻辑层中使用领域模型中使用服务层才 能发挥出最大的优势,如果说我们在业务逻辑层还是使用非领域模型的模式话,服务层的作用仅体现在解耦作用.其实在业务逻辑层采用领域模型时,我们前面说的持 久化透明的技术,其实我们可以通过服务层来做,我们在服务层中处理领域对象信息的持久化操作.当然本篇可能不会深入讨论持久化透明的具体实现,后面会单独开 篇来讲述,我们先来回顾下上篇讲解的内容:  上图

HBase系统架构及数据结构(转)

原文链接:Hbase系统架构及数据结构 HBase中的表一般有这样的特点: 1 大:一个表可以有上亿行,上百万列 2 面向列:面向列(族)的存储和权限控制,列(族)独立检索. 3 稀疏:对于为空(null)的列,并不占用存储空间,因此,表可以设计的非常稀疏. 下面一幅图是Hbase在Hadoop Ecosystem中的位置. 二.逻辑视图 HBase以表的形式存储数据.表有行和列组成.列划分为若干个列族(row family) Row Key 与nosql数据库们一样,row key是用来检索记

petshop4.0 具体解释之中的一个(系统架构设计)

前言:PetShop是一个范例,微软用它来展示.Net企业系统开发的能力.业界有很多.Net与J2EE之争,很多数据是从微软的PetShop和Sun的PetStore而来.这样的争论不可避免带有浓厚的商业色彩,对于我们开发者而言,没有必要过多关注.然而PetShop随着版本号的不断更新,至如今基于.Net 2.0的PetShop4.0为止,整个设计逐渐变得成熟而优雅,却又非常多能够借鉴之处.PetShop是一个小型的项目,系统架构与代码都比較简单,却也凸现了很多颇有价值的设计与开发理念.本系列试

【转】.NET/ASP.NET Routing路由(深入解析路由系统架构原理)

阅读目录: 1.开篇介绍 2.ASP.NET Routing 路由对象模型的位置 3.ASP.NET Routing 路由对象模型的入口 4.ASP.NET Routing 路由对象模型的内部结构 4.1]UrlRoutingModule 对象内部结构 4.2]RouteBase.Route.RouteCollection.RouteTable 路由核心对象模型 4.3]RouteValueDictionary.RouteData.RequestContext 路由数据对象模型 4.4]IRou

高并发高负载的大型站点系统架构

大型站点的系统架构须要考虑非常多问题.大型站点有高并发高负载的特点,在面对大量用户訪问.高并发请求方面.主要的解决方式集中在这样几个环节:使用高性能的server.高性能的数据库.高效率的编程语言.还有高性能的Web容器.本文从低成本.高性能和高扩张性的角度来探讨了一些大型站点系统架构须要考虑的问题. AD:WOT2014:用户标签系统与用户数据化运营培训专场 一个小型的站点.比方个人站点,能够使用最简单的html静态页面就实现了.配合一些图片达到美化效果,全部的页面均存放在一个文件夹下,这种站