空间拆分的代价
架构拆分的本质就是空间拆分，这在之前的文章中已经探讨过了。一个事物在进行空间拆分之后，必然会变成一个一个不同的个体。每个个体从原有事物中独立出来之后，会形成各自一个一个的独立生命周期。
既然是独立生命周期，那么就意味着对原有事物做架构拆分的人——也就是架构拆分主体，他必须要管理这些新出现的一个一个独立生命周期。也可以看到，有了架构才会出现管理，做管理的人不懂架构是不行的。
但是大部分做架构拆分的人，都没有意识到这一点。大多数人只注意获得架构拆分的好处，而忽略了拆分出来的子生命周期也是需要管理的，只有管理好子生命周期才能够得到架构拆分的好处。
比如做技术的人，在企业经过一段时间的锻炼之后，掌握了某种技术。往往他们就会开始去思考如何把技术变现，以求自身利益最大化。比较流行的方式当然就是去创业。
而创业则等于形成一种新的社会分工，也就是对社会的一个架构拆分。拆分的结果，形成了一个新的公司，也就形成了一个新的生命周期。这个新的生命周期必须先要健康的运转起来，技术才能够派得上用场。而要推动运转这个新生命周期，则需要先注册公司，准备资金，需要和税务、法务打交道，要招人，要社保…。这个时候，已经累的够呛了，但是离运用想要变现的技术还远着呢。
公司成立好了，接下来为了要形成订单，还需要先找到客户。为此，还需要先把技术形成产品，以便形成商品进行销售。为了形成产品，则需要巨大的投入。为了找到客户，则需要巨大的营销成本。而这些工作，光只是一个人是不够的，还需要先做自身的架构拆分后，再招人来帮忙。如果没有受过架构方面的训练，这个架构拆分本身就很容易产生新的问题。即便成功的对自身工作 进行架构拆分之后，则又形成了新的生命周期，新招来的人则会负责推进这些生命周期。那么这些新招来的人当然也是需要管理的，他们的生命周期也是需要推进的，需要与他们签订合同，发工资，交社保，等等等等。
回头再看看，在企业内部掌握并运用这个技术，只需要关心这个技术本身的生命周期就足够，事情简单太多了。
很多技术创业者满腔热情，只看到了自己的技术的好处，没有注意到架构拆分后，要管理子生命周期的成本，最后往往因此不堪重负，最终导致失败。
所以做架构拆分的人，他必须要管理拆分之后子生命周期的全生命周期，才能够享受到架构拆分的好处，大家对此要有清醒的认识。他必须要了解拆分后子生命周期的全生命周期活动，而不是仅仅关心自己想要的其中那一个活动。 所以做架构拆分时，要谋定而后动：只有管理好每个独立子生命周期的成本自 己可以承受，并且有应对的办法，才可以做架构拆分。
当然还可以进一步做架构拆分，请一个人来开车，让他来执行并推进这些生命周期。这又意味着进一步的成本的付出，因为还要新增负担管理司机的生命周期，需要支付工资等等。
不清楚这些新出现的子生命周期的代价，贸然的去买车，那么也只会给自己带来麻烦。这种情况之下，坐地铁反而是经济实惠的。
对于软件开发工作者而言，在对代码做架构拆分时，同样也必须管理好架构拆分后所形成新组件的全生命周期。比如把一个应用拆分为两个子应用后，那么两个子应用的全生命周期都要管理起来，哪怕只是需要子应用的某一个服务。
当然，人们常用“非功能性需求”来说明这一点，但是往往得不到重视，也 不够全面。或许是因为“非功能”这一概念仍然仅仅是附带在“功能”上，没脱离“功能”的阴影。因此我也很少用“非功能性需求”这个词汇，因为无法用“功能”去定义它。
只有回归到软件自身的生命周期上，才能够正确理解所谓的“非功能性需求”：其关注点并不在于“功能”，而是在于保障功能自身的健康，并保证功能可以被正常访问到。因为想要得到子应用的某一个功能——这只是充分条件，只是决定了该子应用具备独立生存的资格；但是这还远远不够，先必须得让这个子应用能够正常生存下去——这是必要条件，因为只有健康活着才能够被访问。 只有充分条件和必要条件同时都满足，这个子应用的生命周期才算是完整了， 该子应用的功能才能够正常运转并接受访问。
因此，所谓的“非功能性需求”，指的就是软件得以正常生存并对外提供服务的必要条件