去年参加过一次软件模型设计的培训，有位老师基于公用事业行业（水、电、气、热）讲解了一下模型设计的最佳实践。正好这几天又碰到了模型设计的问题，就把当初的学习思路整理一下。

　　一般来说，我们要做一个软件产品，首先需要找到要解决的问题，分辨出问题关联的各个事物的关系；然后进行抽象并建立对应的数据模型；最后通过程序语言实现出来。这个过程简单来说，可以分为需求分析、模型设计、软件实现三个阶段。

　　而模型设计，就是其中最关键的一环。它承上启下，对接上层的业务需求，又面对下层的技术实现。

　　如果模型设计的不够灵活，一旦面对多变的业务需求，开发人员绝对有问候你家属的冲动。

　　所谓模型设计，有时候也叫业务建模（Business Modeling），用某百科上的说法，它是以软件模型方式描述企业管理和业务所涉及的对象和要素、以及它们的属性、行为和彼此关系，业务建模强调以体系的方式来理解、设计和构架企业信息系统。

　　从这可以看出，软件产品的关键在于模型设计，模型设计的关键在于找到“对象”，梳理“关系”。

　　话不多说，就拿公用事业行业里面的用电来作为例子，有买过房的同学应该都去供电所办理过用电申请。

　　首先咱们需要向营业员提供一些证件和资料，比如房产证、身份证、手机号等一堆信息，然后营业员把这些信息录入到系统中，签一个用电的合同，后面就根据这些信息向咱们收电费了。

　　这个业务受理的过程，如果简单的处理，咱们可以设计一个客户对象，并把这些证件、资料信息，以及合同的电价信息都存到这个对象中，没什么乱七八糟的关联关系，基本可以满足正常的用电需求了：

　　但是这样就有一个弊端，当一个单位或个人有几套房子的话，就要有多个用电申请，每个用电的地方都有一个账户来算账，上面的这个客户模型明显不够用了，也不灵活，所以逐步演进成这种模型：

　　上图就是我们常见的三户模型，包括客户、用户、账户。实际上大部分营业受理类模型，比如电信、电力等行业，都是这么设计的，它可以满足绝大部分的业务场景。

　　但是如果我们要做一些用电变更的业务，就会发现这里的模型设计还是有一定的问题。

　　比如如果这个客户卖了旧房子，并要迁到新房子，这个业务办理的过程就比较麻烦了。

　　一种常见的做法是将原有的用电户直接作废，然后新建一个用电户和合同，这样就会有大量的信息重复录入和保存问题。

　　另外一种做法是直接修改这个用电户地址，然后新增一个合同，这种做法相对减少了信息的重复性问题，但是可能带来历史信息复查的问题。

　　设计模式中有一个重要的，也是最核心的原则，那就是区分变和不变，分开变化和不变的。

　　仔细思考一下，就可以发现，客户、用户、账户都是可以变化的，但是房产是不变的，电表、水表、气表也是不变的。所以我们就可以建立如下图这样的模型：

　　最后，经过进一步的丰富，补充上房产大楼、水电气网络等资源，就会最终形成这样的模型图了。

　　可以看到绿色部分的是业务数据，可以经常变化的；而蓝色部分的是技术数据，基本上是不会变的。

　　通过这样的模型设计，我们可以更灵活的表达这些对象和之间的关系，比如单一房产和多房产：

　　需要表达同时用水、用电的情况，则客户、房产都是公用的，只是用水、用电各自新建一套独立的资料即可：

　　企业用电的情况比较复杂，一个企业可能有工业用电，也有居民用电，这时可以通过不同的用电性质建立不同的合同进行管理；也可能通过主子安装点的定比定量关系来进行管理：

　　PP电子 游戏

　　这套模型除了在表达对象之间关系比较清晰明了，在做各类修改的业务的时候，也很容易处理，比如一个买了新房子要迁出旧房子的过程：

　　可以看到，这次模型设计的重要转折点，就在于将用电地址从用电户中拆出来，形成了一个独立的房产对象，从而解决了变化的用电户与不变的房产之间的关系。

　　通过这个模型，也可以发现，它基本上就是现实世界中的对象的映射：一个东西在现实世界中是可以独立表达的，在软件世界中就被设计成一个独立的对象与它对应。

　　更进一步，一个对象在现实世界中拥有什么特性，在软件世界中就拥有什么属性；在现实世界中拥有什么行为，在软件世界中就拥有什么函数；在现实世界中与哪些事物存在怎样的关系，在软件世界中就应当与它们发生怎样的关联。PP电子的官方网站