系统设计和系统划分的基本思路
今天要说说这两个定律，一个是墨菲定律，另外一个是康威定律。
有人说:在系统设计时，可以以“墨菲定律”作为警醒。
墨菲定律:
任何事物都没有表面看起来那么简单。
所有的事都会比你预计的时间长。
可能出错的事总会出错。
如果你担心某种情况发生，那么他就更有可能发生。
"任何事物都没有表明看起来那么简单"，比如在做系统分析和设计的时候，你总会发现，刚刚开始总会那么一帆风顺，但是呢？最后你会发现，一切都没有你想象的那么简单。比如当初在做酒店系统后台的时候，在做之前没有考虑三级模型，也就是Root-Admin-Manage，直接上手就是Manager,设计之初也只单单考虑Manager,可谓做的是非常顺利，因为很So Easy。随便拉个培训的基本都能做。后来发现考虑不周，没有想象的那么简单，最后经过讨论和分析指定好对应的方案，预计在两周内完成三级模型，简单的说就是权限开发。那个时候我们并没有用shiro。用的仅仅只是jsp和jstl等。最后过来应验了“所有的事都会比你预计的时间长”。因为计划跟不上变化，各种需求不断的迎面而来。最后近一个月才成型。不过虽然成型，但是问题的确不少，因为当初为了赶进度，不顾一切，有的时候发现许多地方有问题，但是由于精力有限无暇兼顾，但是到最后虽然是完成了任务，但是心中不免忧虑，觉得可能有几个地方会出问题，但是“可能出错的事总会出错”。最后好几次加班就是因为这个原因。
还有些时候在与安卓方面对接的时候总觉得哪里会有问题，但是当时测着却没有问题，上线以后，不免担心起来，最后果然还是应验了墨菲的那句话,"如果你担心某种情况发生，那么它就更有可能发生"。
还有人说:在系统划分时，应该考虑康威定律。
康威定律:
系统架构是公司组织架构的反映。
应该按照业务闭环进行系统拆分／组织架构划分，实现闭环／高内聚／低耦合，减少沟通成本。
如果沟通出现问题，那么应该考虑进行系统和组织架构的调整。
在合适时机进行系统拆分，不要一开始就把系统／服务拆的非常细，虽然闭环，但是每个人维护的系统多，维护成本高。
"系统架构是公司组织架构的反映",这句话，你可以这么理解，系统架构可以分为两个方向，一个是业务架构，另外一个是技术架构。这么一说，就更好理解的，业务架构，以公司的业务为主，技术架构是来实现业务的，两者相辅相成。不经意中就反映出了公司的组织架构。
"应该按照业务闭环进行系统拆分／组织架构划分，实现闭环／高内聚／低耦合，减少沟通成本"。这不免让人疑惑，业务闭环是什么？简而言之的说，就是你要想清楚你的盈利模式。
根据盈利模式进行系统拆分和组织架构划分，所谓的系统拆分为的是对应不同的人群提供不同的服务，简单举个例子，比如去国家图书馆看书，对应不同的人群有不同的看书地方，比如大人、小孩、残疾人、老年人等等。残疾人失明，通过盲文阅读，但是有的残疾人失明又失去双臂，但是耳朵却很灵，听书就比较适合他。从系统的拆分归类划分业务，然后进行组织架构划分，谁擅长那些业务就由谁负责。
“高内聚和低耦合”，更是项目灵活变化的关键。最好的状态就是像水一样，放在圆的容器就是圆的，放在方形的容器就是方的，适应变化，并不会出现前期以牵一发而动全身，但是这仅仅只是理想的开发状态。现实却因为沟通的原因和各种其他的原因在执行这个原则时出现阻碍。
我个人最推崇的就是最后这句话,"在合适时机进行系统拆分，不要一开始就把系统／服务拆的非常细，虽然闭环，但是每个人维护的系统多，维护成本高"。
比如最近我在做业务拆分时，我并不会将业务拆的非常细或者是直接拆完上分布式，因为那样成本会非常高，拆的细意味着每个人维护多个系统，上分布式，目前的业务也没有多大必要。
记得有位哥们说的好，不要为了分布式二分布式。
我目前拆分的，仅仅只是将一个拆分成两个，一个是后台系统，一个是专门作为共享XX系统直接对接客户端。后台可通过Ajax直接获取共享XX系统的相关数据。之前都是在一个系统，这个人改点东西或者上点新功能，那个人删点东西改点东西，最后全部都在一个项目上，即增加项目的复杂性，又增加了沟通的成本。所以才决定进行系统拆分，当需求非常强烈，项目面临不得不拆分的场景时，我想这就是合适的时机。另外还是那句话不要拆的非常细，拆个大概，总的来说，就是两者系统不包含彼此的相关代码，可惜的是我目前还是没有做到这一点，因为A系统可以完全不依赖B，但是B在某些代码中却依赖A。这是一个很操蛋的问题。不过也不算很严重，至少目前分离出来后，没有发现什么大问题，测试也一切正常。
系统设计和系统划分的基本思路相关推荐
- Hadoop+hive+flask+echarts大数据可视化项目之hive环境搭建与系统数据的分析思路
Hadoop+hive+flask+echarts大数据可视化项目(四) --------------hive环境搭建与系统数据的分析思路---------------- 关注过Hadoop+hive ...
- 电商新零售系统划分及供应链系统流程详解
[声明在先]:文中所有业务流程及系统设计均由电商标准流程改造,不具有任何商业倾向性. 前序文章讲解了产品经理从接到任务开始,到出具电商后台整体解决方案的过程,本文重点讲述电商后台核心系统的划分及主营供 ...
- Exchange Server 2003邮件服务器系统的基本部署思路
<?xml:namespace prefix = st1 ns = "urn:schemas-microsoft-com:office:smarttags" />以下内 ...
- ROS中阶笔记（一）：机器人系统设计—ROS系统下连接外部传感器
ROS中阶笔记(一):机器人系统设计-ROS系统下连接外部传感器 文章目录 01 连接摄像头 1.1 ROS下连接usb_cam 1.1.1 前期准备 1.1.2 问题 1.1.3 安装usb_cam ...
- license程序设计 系统划分 及加密设计 加密算法调用openssl库
license程序设计 系统划分 加密: 加密模块: 1.对称加密算法(AES.DES.3DES) 对称加密算法是指加密和解密采用相同的密钥,是可逆的(即可解密). AES加密算法是密码学中的高级加密 ...
- Niushop分销系统佣金算法设计思路
Niushop分销系统佣金算法设计思路 Niushop分销系统当前设置的分销模式一共有4种,分别是三级分销,区域代理,股东分红,全球分红 三级分销: 1.1 系统设置三级分销 系统可以设置对否开启三级 ...
- 计算机毕业设计ssm基于客户时间窗变化的物流配送管理系统设计ro75j系统+程序+源码+lw+远程部署
计算机毕业设计ssm基于客户时间窗变化的物流配送管理系统设计ro75j系统+程序+源码+lw+远程部署 计算机毕业设计ssm基于客户时间窗变化的物流配送管理系统设计ro75j系统+程序+源码+lw+远 ...
- java毕业设计点餐系统设计Mybatis+系统+数据库+调试部署
java毕业设计点餐系统设计Mybatis+系统+数据库+调试部署 java毕业设计点餐系统设计Mybatis+系统+数据库+调试部署 本源码技术栈: 项目架构:B/S架构 开发语言:Java语言 开 ...
- 记录开发HIS系统体温单的思路历程
记录开发HIS系统体温单的思路历程 一.主要技术:react.es6.svg 二.体温单构成 标题和患者基本信息,固定 日期住院信息等 刻度区及绘图区,也是整个体温单最重要的部分 二.体温单绘制规范 ...
最新文章
- 用Python分析为什么在中国没学历的外教为啥能拿几万高薪？
- lucky前面加a还是an_“不可数”名词前何时加a/an，何时不加？来自本站教师群的两道典型题问答，揭示了规律 白话英语201931...
- （17万浏览量） .NET Core的介绍
- 【转】wpf从我炫系列2----布局控件的使用(下)
- 隐藏的图片在浏览器中的请求
- 3个平台下的ffmpeg——ffmpeg编译
- HDU 5427 A problem of sorting 水题
- Javascript第五章document对象获取标签节点-第六课
- Seaborn学习笔记4
- 关于学习session的一二
- CF989C A Mist of Florescence
- 官方开源的安卓客户端
- unity 3D打不开已建项目或新建项目
- MongoDB 主从复制（Master-Slaver）实验
- 选择WMS仓储管理系统的10条“潜规则”
- OSChina 周二乱弹 —— 好支威有希
- linux内网穿透(内外网服务器端口映射)
- 电商项目—收货地址管理模块开发
- Excel如何提取指定位数数字
- 微商怎么通过QQ引流？微商如何利用QQ加人?微商QQ引流技巧