系统设计和系统划分的基本思路

今天要说说这两个定律，一个是墨菲定律，另外一个是康威定律。

有人说:在系统设计时，可以以“墨菲定律”作为警醒。

墨菲定律:

任何事物都没有表面看起来那么简单。
所有的事都会比你预计的时间长。
可能出错的事总会出错。
如果你担心某种情况发生，那么他就更有可能发生。

"任何事物都没有表明看起来那么简单"，比如在做系统分析和设计的时候，你总会发现，刚刚开始总会那么一帆风顺，但是呢？最后你会发现，一切都没有你想象的那么简单。比如当初在做酒店系统后台的时候，在做之前没有考虑三级模型，也就是Root-Admin-Manage，直接上手就是Manager,设计之初也只单单考虑Manager,可谓做的是非常顺利，因为很So Easy。随便拉个培训的基本都能做。后来发现考虑不周，没有想象的那么简单，最后经过讨论和分析指定好对应的方案，预计在两周内完成三级模型，简单的说就是权限开发。那个时候我们并没有用shiro。用的仅仅只是jsp和jstl等。最后过来应验了“所有的事都会比你预计的时间长”。因为计划跟不上变化，各种需求不断的迎面而来。最后近一个月才成型。不过虽然成型，但是问题的确不少，因为当初为了赶进度，不顾一切，有的时候发现许多地方有问题，但是由于精力有限无暇兼顾，但是到最后虽然是完成了任务，但是心中不免忧虑，觉得可能有几个地方会出问题，但是“可能出错的事总会出错”。最后好几次加班就是因为这个原因。

还有些时候在与安卓方面对接的时候总觉得哪里会有问题，但是当时测着却没有问题，上线以后，不免担心起来，最后果然还是应验了墨菲的那句话,"如果你担心某种情况发生，那么它就更有可能发生"。

还有人说:在系统划分时，应该考虑康威定律。

康威定律:

系统架构是公司组织架构的反映。
应该按照业务闭环进行系统拆分／组织架构划分，实现闭环／高内聚／低耦合，减少沟通成本。
如果沟通出现问题，那么应该考虑进行系统和组织架构的调整。
在合适时机进行系统拆分，不要一开始就把系统／服务拆的非常细，虽然闭环，但是每个人维护的系统多，维护成本高。

"系统架构是公司组织架构的反映",这句话，你可以这么理解，系统架构可以分为两个方向，一个是业务架构，另外一个是技术架构。这么一说，就更好理解的，业务架构，以公司的业务为主，技术架构是来实现业务的，两者相辅相成。不经意中就反映出了公司的组织架构。

"应该按照业务闭环进行系统拆分／组织架构划分，实现闭环／高内聚／低耦合，减少沟通成本"。这不免让人疑惑，业务闭环是什么？简而言之的说，就是你要想清楚你的盈利模式。

根据盈利模式进行系统拆分和组织架构划分，所谓的系统拆分为的是对应不同的人群提供不同的服务，简单举个例子，比如去国家图书馆看书，对应不同的人群有不同的看书地方，比如大人、小孩、残疾人、老年人等等。残疾人失明，通过盲文阅读，但是有的残疾人失明又失去双臂，但是耳朵却很灵，听书就比较适合他。从系统的拆分归类划分业务，然后进行组织架构划分，谁擅长那些业务就由谁负责。

“高内聚和低耦合”，更是项目灵活变化的关键。最好的状态就是像水一样，放在圆的容器就是圆的，放在方形的容器就是方的，适应变化，并不会出现前期以牵一发而动全身，但是这仅仅只是理想的开发状态。现实却因为沟通的原因和各种其他的原因在执行这个原则时出现阻碍。

我个人最推崇的就是最后这句话,"在合适时机进行系统拆分，不要一开始就把系统／服务拆的非常细，虽然闭环，但是每个人维护的系统多，维护成本高"。

比如最近我在做业务拆分时，我并不会将业务拆的非常细或者是直接拆完上分布式，因为那样成本会非常高，拆的细意味着每个人维护多个系统，上分布式，目前的业务也没有多大必要。

记得有位哥们说的好，不要为了分布式二分布式。

我目前拆分的，仅仅只是将一个拆分成两个，一个是后台系统，一个是专门作为共享XX系统直接对接客户端。后台可通过Ajax直接获取共享XX系统的相关数据。之前都是在一个系统，这个人改点东西或者上点新功能，那个人删点东西改点东西，最后全部都在一个项目上，即增加项目的复杂性，又增加了沟通的成本。所以才决定进行系统拆分，当需求非常强烈，项目面临不得不拆分的场景时，我想这就是合适的时机。另外还是那句话不要拆的非常细，拆个大概，总的来说，就是两者系统不包含彼此的相关代码，可惜的是我目前还是没有做到这一点，因为A系统可以完全不依赖B，但是B在某些代码中却依赖A。这是一个很操蛋的问题。不过也不算很严重，至少目前分离出来后，没有发现什么大问题，测试也一切正常。