软件工程里最有意思也最有挑战性的地方就在于系统设计，这就像在创造一个世界，而我们就是这个世界的上帝，这个世界里的运行法则完全由我们来制定，我们说要有光就有光，说让物体离开手是往天上掉的它就能往天上掉，但是我们如果真的这么随心所欲的来制定运行法则，那这个世界就是一盘乱麻，因此，我依我作为前端的浅薄的经验，妄然的总结了创造“世界”的一些方法论，创造好一个世界，其实就是理清这个世界里的各个单位的关系，让他们各司其职，一切井然有序，有主次之分，并且每个单位都是有其生命周期的，既要给每个单位成长的空间也要防止它们成长的盘根错节，牵一发而动全身。

要想理清这些单位之间关系，我觉得首先就是明确他们各自的本质是什么，这和需求分析里的明确需求边界相似，但是还是有根本的区别，需求边界指的是这些单位的功能范围，尤其是在快速迭代的产品里，每个版本都会有不同的需求，也就会有不同的需求边界，所以这种需求边界一方面虽然是用来限制用户需求的，但是另一方面却也是基于用户需求的。而我说的明确各个单位的本质，是经过对业务的高度抽象分析，从系统层面对某个单位本身作出的一种限制，并且这种限制是贯穿系统全部生命周期的，是比较稳定不轻易改变的一种限制，而我这么做的理由就是，”限制“会带来两个好处：自由与安全，（不受限制的自由带来的是灾难，限制下的自由才是真正的自由）这句话我想懂的人自然会懂。 从另一个方面说，明确各个单位的本质也是系统设计里的第一个有挑战性的地方，需要对相关业务领域有较深的认识和比较强的抽象能力。举个🌰，公司的停车收费业务里有个优惠券和停车卡的概念，优惠券是一次性的，绑定到用户手机号上的，用户可以通过优惠券对订单费用进行减免，停车卡的有效期是长期的，绑定到用户车牌上的，每个停车卡对应着一个相应的订单费用减免规则，起初，我以为优惠券和停车卡的本质都是一种计费规则，只是一个是绑定到手机号上，一个绑定到车牌上。于是在设计停车卡时，都是基于这点进行思考的。后来在与同事讨论时，才发现系统现有的逻辑里，停车卡还起到一种车辆标识的作用，并且这种标识作用是进行与计费无关的逻辑。所以，我之前设计的停车卡并不能适应系统的需求，接下来我有两种解决方案，一是将停车卡的本质确定为计费规则和车辆标识，二是将停车卡的本质确定为只是车辆标识，再重新设计一个本质为计费规则的实体用来实现优惠券和停车卡的计费功能。我倾向于第二种解决方案。

另外我认为不能让外界的需求直接决定系统是如何设计的，系统是如何设计的也不会直接限制需求的实现。因为系统设计的本质是将业务领域经过抽象分析，整合出若干的实体和实体之间的关系，然后在软件世界里用逻辑来表达这种实体及关系。而用户需求的本质就是把部分关系给表现出来让用户可见，或者是给这些实体之间添加新的关系。可以说用户需求只是系统的一个子集，所以如果直接由需求来决定系统设计，那结果就是每次需求都得来次重大重构。反过来，正是因为系统的本质是在软件世界里模拟出业务相关的现实世界，那能在现实世界走得通的需求在系统里自然也能走得通，所以说系统设计不会直接限制用户的需求，不过前提是各个实体的本质确立的没有问题，而这个的前提是对业务领域的深入理解，当然谁也不能保证万无一失，所以在发现实体的本质出现偏差时，进行重构是很有必要的。另外，用户的需求也要是合理的才行，而如何判断一个需求是否合理，在前年写的文章《产品思考》里表达过。