基于BSS业务系统构建的思考总结

模型

在接触一个系统之前，首先想到的是该如何去存储和处理数据？数据作为系统的核心，是系统中是最重要的“资产”。应该说系统的所有一切都是在为数据而服务，同时数据也是对业务的抽象，是支撑业务的最底层的支柱。

软件最终支持的是业务，不但要支持，还要能够高效率的支持。当下的软件工程无论是从原始的瀑布模型（可以介绍一下瀑布模型，以及瀑布模型解决的问题，瀑布模型带来的结果、思考以及在当下的敏捷中是否已经过时？），到流行的敏捷、迭代，再到xxx。想要达到的最终目的就是为了能够快速、高效的完成业务功能的交付。

但是，仅仅是从软件工程单一角度去考虑，往往是以偏概全。笔者所在的公司，就是非常注重软件工程的“大公司”。但是，从我从业的这几年的思考。想要达到快速的交付，而且还要能够提供更多的复用。仅仅靠软件工程是很难做到的，软件是一个系统工程。其实和造车（我一直比较喜欢丰田的体系）等其他工程是没有区别的。必须从软件涉及到的方方面面入手，将任何一个细节都抠得很细，将任何一个细节都做到极致。软件工程往往只是一个辅助的手段（但是是很重要的管理控制手段），可以帮助团队高效的运作。

这个运作其实包含有很多东西，既有组织间的合作（可以拆分一个小节来写）。也有软件开发自己的特有的流程，例如设计、测试、开发、集成、集成测试、发布、生命周期结束（以往的瀑布模型强调的是大系统、大软件的开发流程，这个问题往往会导致大量的浪费。在各个环节都会存在浪费，例如设计必须要等所有的需求都分析完和设计完，每一个环节结束后，产生“明确”的交付文档才能进入下一个环节。这就导致有部分简单的需求，环节的周期是以最复杂的功能点为依据。导致周期拉长，而且会浪费其他人力。也会导致环节的处理时间拉长，导致整个所有的交付周期变长）。

所以，本文一开始就先从模型开始介绍。模型的好坏直接影响到业务功能的实现，以及软件的最终目标——达到快速交付。模型的设计需要衡量各个方面的需求，有可能会在一个方面满足需求，但是却在另一个方面存在缺陷。例如，为了达到动态扩展的目标。可能会采用纵表的设计，来对横表中的记录进行扩展，如在纵表中使用Code＋Value的方式来记录扩展数据。这种设计在扩展性上的灵活性是非常具有优势的，但是在数据的存储和数据访问的性能会存在问题。如何进行取舍是设计者需要面临的重要决策问题。

心得体会：如果只寄希望于在模型上解决所有的问题，包括业务上面临的问题。这往往是不切实际的，根据“当前”业务的需要，符合当前业务的目标和发展需要才是设计上需要考虑的重要因素。

软件的主要构成：数据模型、系统架构、编码实现这三者其实都是管理的艺术，数据模型就是对数据的管理，系统架构就是对功能的管理，编码实现就是对代码的管理。

这三者相辅相成，没有谁更重要，谁次要的一说。我一直认为，软件的架构不能仅仅只考虑技术架构、应用架构、部署架构。还应该有一个最重要的开发架构（包结构设计、代码层级机构的设计、类和接口的设计）。将开发的实现进行合理的设计、规划和管理。做架构就是做管理，就是管理的艺术。数据模型就是对数据的管理，系统架构就是对功能的管理，编码实现就是对代码的管理。合理的架构一定可以提升软件研发的效率，使得软件研发可以聚焦在最本质的问题上，从而使得软件交付的效率得到提升。

我所在的“大公司”往往只注重所谓的模型、架构，而忽略了实现。其实，软件最最重要的交付件就是源代码。源代码在管理、设计和编写的过程中都是非常的讲究。往往源码的管理和设计做到极致，会极大的提升软件效率的开发。这并不是任何人都可以做到的，只有经常思考，经常总结和进行改进。

在开始一个业务系统的实现前，往往需要对该系统所面临的业务做一个充分的理解和抽象。除了对业务理解之外，最重要的就是要理解业务背后的数据，因为这些数据承载了对业务支持的使命。在BSS系统中，所面临的最重要的业务就是向客户销售电信类的服务产品，并且能够支撑好客户对这些产品的使用、费用的计算和收取、以及快速的推出新业务。 BSS的目标： 1、快速的推出业务。快速推出业务，就意味着在市场上占有主要优势。而且，推出的业务可以是现有业务的组合。从而，更好的复用现有的业务，降低业务成本，提升单位利润率； 2、快速的想客户销售业务； 3、给客户提供优质的服务和使用体验； 4、及时的对业务的使用进行费用计算和收取，避免带来经济损失；

我们从BSS业务的典型场景开始介绍。场景1：购买电话卡这是最简单的场景，即你去移动营业厅去购买一张SIM卡。购买完后，插入手机，就可以开始进行移动通话了。这个场景，我们暂且称之为个人开户（移动）场景2：购买电话卡，同时还可以开通一些其他的功能在你去营业厅购买SIM卡的同时，你同时还有一些更高级的需求，例如接听电话时，我想看到对方的号码已决定我是否接听（来电显示）。或者其他的一些在电话基础上的附加功能：彩信、彩铃、呼叫转移等等。场景3：安装固定电话你去营业厅要求在自己家安装一部固定电话，同样的也会有在此基础上的附加功能：彩信、彩铃、呼叫转移等等。场景4：家庭成员的手机共享通话时长、数据流量你去营业厅购买了三个手机卡，而且要为这三个手机卡购买可以共享的通话时长和数据流量，以便在这三个手机卡之间共用。

以上场景就是典型的BSS需要支撑的业务场景，下面会基于以上场景做一个简单的模型分析。模型会介绍以下几个方面：三户模型产商品模型订单模型：电信类订单模型和实物销售类订单模型之间的差异库存模型

从三户模型说起首先介绍几个概念： 1、电信运营商，就是指对电信产品进行销售和服务的企业。挖掘客户在互联领域的需求，为客户提供服务。 2、电信产品或服务。不同于传统产品那种一次性商品的买卖，电信的产品或服务，往往都是带有明显的周期性。在这个周期内，客户用了多少就付多少。类似于水电，在一个周期内（如一个月），你用了多少的量，就按照单价进行计算并付费（现在的运营商越来越管道化进行演进了）。【因此，在考虑模型的时候必须要能够支持这种特性】客户客户概念介绍以上面提到的业务场景1来说，你购买SIM卡的这笔交易，对运营商来说他需要记录你的相关信息，以便以为你提供后续的服务。在这个过程中，需要把你的个人资料录入到系统中。同时，你购买的这个动作，也会做相应的记录。记录你什么时间，购买了什么。（之后，就会根据这些数据来为你提供服务。你打电话或者接听电话时，这个购买记录就会起到关键作用，它会决定你是否能够享受到这样的服务。）运营商记录了你的相关资料，同时对于运营商来说，他需要一个概念来称呼“你”，客户这个概念就是为了达成这样的目的。从商业的行为和过程来看，购买SIM卡和你去商场买东西，甚至是去菜市场买菜的动作是没有区别的。总结一下客户的概念，客户即指运营商营销、服务的对象，可以是个人也可以是集团、企业。（延伸来说，客户就是购买了商家商品，需要享受商家提供服务的主体。）在你进入营业厅购买SIM卡的这个过程中，在购买前“你”对于运营商来说就是潜在的客户。当在购买这个动作结束后，那“你”就是运营商的在用客户了。这个时候，运营商就可以根据你购买的东西来找到你的数据资料，并根据这些数据资料来为你提供业务服务，包括计算费用、收费（当然这个是通过另一个模型来支持的，将在后面介绍）。因此，综合来看客户会存在两种状态：未产生购买行为或者已产生购买行为。未产生购买行为的客户一般称为潜在客户，这些客户可能已经和运营商产生了一些联系，但是仍然没有购买运营商的服务。已产生购买行为的客户一般称为在用客户。对运营商来说，需要增加潜在客户的接触，并最大限度的将这些潜在客户转化为存量客户。同时，还要尽可能的保留住在用客户。客户模型设计设计目标： 1、为了客户的资料数据的采集而设计，这要求模型设计的完备性； 2、能够提供高效、便捷、可靠的数据供业务使用，这要求模型设计的可靠性、高效性、一致性。【需要补充模型的维度图】首先来看完备性要求针对客户需要采集的信息，我们很自然的可以想到需要采集的客户资料主要包括： 1、客户的自然信息，如姓名、年龄、学历等、证件、联系信息、地址信息等，作为自然人的天然的信息。 2、客户的属性信息，作为管理系统，必须要要对客户做相关的数据分析。因此，为了满足该要求，需要针对客户定义相关的属性。例如，类型、等级、忠诚度、状态等信息。 3、客户接触信息，主要是为了记录客户交互过程所产生的数据信息。作为运营支撑系统的重要数据，可以为后续的客户相关的分析，并未业务的开展提供指导。第一次模型设计（方案1）：

根据以上信息，很容易得到以下的模型原型设计（字段等细节的设计就不过多的描述了，可以参考Demo示例中的字段设计）：

从模型的相关维度来看该方案的设计，数据的完备性较高这个设计方案包括了可以支撑业务所需的数据要求，同时按照数据的相关性做了数据的归类。对数据的操作，也可以使用最小的交互完成。例如，记录一次客户的证件信息。最多只需要操作2张表：基本信息和证件信息（可以单独更新和编辑证件信息，如果是新增则只需要编辑1张表）。记录客户的完整信息，需要操作4张表。地址信息和联系信息可以单独操作，只需要操作对应的表即可。

至此，基本的模型原型概念设计基本完成。但是，这里会发现有一个问题。这里的客户基本信息所包含的信息，如姓名、年龄、学历等等都是针对个人客户的。业务系统不仅仅要支撑面向2C的业务，还有面向2B也就是企业的业务。因此，还需要针对企业客户定义相关的信息。因此，模型上考虑对企业的支持。通过抽象设计，定义“组织”实体对应于“个人”的模型定义。其中，个人可以作为“组织”的成员而存在，通过定义成员信息来表达。一个个人可以同时归属于多个组织，但是不一定代表归属于多个企业，因为组织可以表达的范围更广。例如，企业可以作为组织，家庭也可以作为组织，或者是一个团队、团体（公益组织）等都可以作为一个组织来表达。一个个人，在社会上可以参与不同类型的组织。下面针对个人和组织这两大核心模型来作进一步的探讨，我们可以看到：个人和组织都会关联到一些公共的信息，如：证件、联系、地址。以及客户属性、客户接触等。而且，在实际的运营过程中，会有这样的情况出现。一个个人。他既可以是运营商的客户，也可以作为运营商的一个片区的业务代理人。通过他扩展业务，同时向其支付一定的佣金作为酬劳。就模型的设计来说，在BSS领域的TMF规范中有定义“参与者”这个概念，含义就是和运营商有交互的主体。通过定义一些主体的扩展信息，来进一步表达更具体的信息。如是个人还是组织，是客户还是合作伙伴。“参与者”作为一个虚拟的概念，其主要承担了数据关联的职责，再通过这种关联关系来表达不同的业务含义。思考：这样设计的模型真的好吗？首先从数据处理的复杂度上来看。方案1中，只有客户表

【模型设计对代码带来的影响和思考】代码层面，如何快速支持字段的变更（添加字段）。框架需要解决的问题，Hibernate需要“编译”一次，生成映射文件和Entity代码（元数据）。其实也很简单了，但问题是需要重新两步：1、工具生成；2、更新代码。最简单的做法，框架层面可以自动检测数据表的结构。发生变更时，自动刷新代码。我曾经写过一个小工具，就是检测数据库的表结构是否发生了变化（每天定时检测）。如果发生了变化就会自动调用Hibernate的工具重新生成映射文件和Entity的java代码，并上传到代码管理库，同时群发邮件通知开发人员。 DAO层 Business层，Business层使用DAO层的API，来实现业务逻辑。 DAO层的问题是，对于具有关联关系的表。其API的封装，应该在主数据的数据操作类中。同时，为了避免分库分区带来的麻烦，可以考虑不使用底层的SQL来实现数据的处理，而是调用其他DAO的API？如果不提供，那么就在Business层去组合。这两种做法的对比，功能实现没有本质区别，但是在包管理上却有本质的区别。参与者表：参与者仅仅是作为一个关联数据存在，也就是所谓的关联表。

同时，这里还有一个重要的概念。一个主体（个人或者组织）和在运营商进行交互时，不一定只是作为客户。例如，一个个人主体。他既可以是运营商的客户，购买了运营商提供的服务。也可以作为运营商的业务代理人，运营商通过他扩展业务，同时向其支付一定的佣金作为酬劳。那么针对这种情况，在模型上该需要如何去支持？这种情况，当主体作为运营商的业务代理人时，其实对于运营商来说就是它的一个“合作伙伴”，而且是代理商类型的合作伙伴。运营商在记录“合作伙伴”时，同样需要定义基本信息、证件信息、联系信息、地址信息等。因此在设计“合作伙伴”的模型时，如果在数据的存储时仍然将这些数据进行独立存储，那这就属于冗余存储。因为，这个主体作为客户存储了一份基本信息、证件信息、联系信息、地址信息等。而作为“合作伙伴”也同样存储了一份。那么，这些数据该如何复用呢？是不是可以考虑，把这种角色的信息抽象出来，独立记录，而仅仅通过关联关联到这些会被重复记录的数据上呢。答案是肯定的，从当前的分析来看，只需要抽象一个“角色”模型来表达这种在运营商中承担不同职责的身份信息，同时抽象一个“参与者”的概念来表达可以被复用的信息，通过建立不同的角色来表达这些信息的在一次和运营商交互中的身份信息。我们将模型做一下调整，如下：用户——改称为订购实例用户是指正在使用由电信运营商（包括第三方合作伙伴）提供的产品的组织、个人，由于已有了客户的信息。所以，用户主要用来表达客户与产品关联的实例信息、状态信息等。例如，一个客户可以订购多个产品，如场景2。此时，会有一个用户信息，且对应于多条订购的产品实例信息。通俗来讲，用户是为了表达客户在一次消费中，和运营商建立的购买关系以及使用的信息。也许有人会问，这种购买关系使用直接使用订购的产品实例信息来记录不就好了？之前有提到过，电信类产品和服务的特点是具有周期性。需要数据能够表达出以下的信息： 1、订购的关系，即购买了哪些产品或服务； 2、周期，一般是以一种隐含的方式来表达； 3、状态，为什么会有状态？就是因为有周期的关系。在一个周期内如果存在欠费的情况，那么用户是状态就要发生变更，以便对用户的消费行为产生干预。如果只是用订购关系，则是没有办法完整的表达以上信息。举个例子，针对场景2。如果仅仅记录订购关系，那么就会变成一个主体商品+三个附属商品的订购关系记录。而且，这四条记录的数据对于使用情况的信息表达必须是“一致”的。

客户	商品	状态	使用密码	使用语言
客户1	移动主体商品1	在用	**	中文
客户1	来电显示	在用	null	中文
客户1	呼叫转移	在用	null	中文
客户1	彩铃	在用	null	中文

如果，客户因为一些原因，暂时暂停使用该号码。那么，这个时候就需要将客户的这个行为记录下来，表示当前暂时使用。

客户	商品	状态	使用密码	使用语言
客户1	移动主体商品1	暂停	**	中文
客户1	来电显示	暂停	null	中文
客户1	呼叫转移	暂停	null	中文
客户1	彩铃	暂停	null	中文

技术上需要考虑事务一致性的处理，必须将多条记录的状态同时设置为“暂停”。从这个简单的演示来看，这样的模型设计有一个问题：把订购关系的信息和客户对商品使用的信息混在了一起。也就意味着如果有其中一个信息需要变更，都会引起对该表的修改。例如，客户不需要彩铃了。那这里就需要操作这张表，将彩铃的记录删除。同时，如果修改了对商品的使用的信息。如，将使用语言修改为ENG，那么需要将对应的每条记录都进行刷新。依据功能单一性原则，模型需要支持这种单一性的诉求，避免带来不必要的数据抢夺的问题。多当前模型的设计做一个简单的优化，考虑将两者的功能拆分出来。客户的订购记录只用来记录客户订购了哪些商品，以及订购时所产生的订购相关的信息。而使用“用户”来表达客户将来要怎么使用这次订购的商品。

客户	用户	状态	使用密码	使用语言	用户等级	用户信用度
客户1	用户1	在用	**	中文	A	60

订购信息：

用户	商品	是否主体商品	接入号码
用户1	移动主体商品1	Y	13409611871
用户1	来电显示	N	null
用户1	呼叫转移	N	null
用户1	彩铃	N	null

把号码实例化到订购实例信息中是否合适？

考虑一种场景：客户改号？如果将号码存放在订购信息中如何体现？

客户	用户	状态	使用密码	使用语言	用户等级	用户信用度	接入号码
客户1	用户1	在用	**	中文	A	60	13409611871

用户的模型设计

商品实例属性、产品实例属性这两张表均为纵表。进行一次优化，将接入号码信息单独剥离出来，同时增加设备信息。接入号码类型，接入号码。账户电信定义：帐户是客户拥有的用来支付指定的电信产品服务费用的实体。帐户描述了具体的支付手段、支付信息，是账务结算的最小单位【，可以分为客户级帐户及产品级帐户】。通俗来讲，客户购买了电信产品后，其就会去使用产品。在使用过程中，必须要对客户的这种使用行为来进行收费。传统产品是一种一锤子买卖的过程，也就是购买这个产品花多少钱。例如手机，5000元一次性买断。电信则是根据使用的情况，通过单价×使用量来得出客户需要支付的费用。因此，账户就是为此而生的。就是为了支付客户的使用用量而产生的费用的。但是，为什么需要账户这个概念呢。直接通过在客户上记录支付方式和对应的支付计划等信息，到期算费执行不可以吗？可以是当然可以的，但是运营商往往会针对客户的消费行为制定一定的优惠。这些优惠，可能是减免、积分、又或者是返还。在支付方式上是没有办法直接记录这些信息的，因此需要一个主体能够把和这些支付相关的信息串联起来。这就是账户概念由来的最主要原因，它负责串联起客户所有和支付相关的信息数据。来直接看下账户相关的模型设计：

账户就是和钱相关的信息，用于支付、返还、优惠、积分等等行为而设计。按照三户模型的设计，客户是可以拥有多个账户的。同时，一个账户也可以为多个用户来支付。打个比方来说，你在商场购买东西。你在商场逛街时，对商场来说就是潜在的客户。一旦购买了某商品，则对商场来说就是存量客户了，因为会有售后服务。购买商品是要支付费用的，这个时候你会有很多的银行卡。每一张卡其实都是一个账户，这里面存有你有多少钱可以用。如果是信用卡，则是你的额度是多少，你的还款信息等。甚至是，银行和商场联合活动，消费多少送多少积分，等等。这个就可以看作是账户了。还可以拿支付宝来说，一个支付宝的账号其实就是一个账户。你可以注册拥有多个支付宝账号，不同的账号可以用来为不同的消费来买单。比如，为家人的消费买单，为你的情人买单（注意别被发现喽）。账户的设立，可以帮助运营商在为客户提供支付的时候带来很多选择和便利性。例如，代付。可以是个人之间的代付，如为妻子、孩子代付。也可以是企业为个人的代付，多在集团业务中使用。账户的模型设计考虑把账期合并到账户中，在业务上表达为账户的属性。

变更为：扩展属性使用： Filed PropId PropCode 属性名称字典 field1 账户业务类型 6010510047 字典编码：PM_ACCOUNT_TYPE field2 客户标识 10050
field3 一点支付标识 6010510401 字典编码：CM_ACCT_1POINT_FLAG field4 付费方式 6010510402 字典编码：CM_ACCT_PAY_METHOD field5 账单介质列表，以|分割 6010510403

一个账户在一个时刻可拥有0 到1 个有效的账务周期实例。【建议将账期合并到账户表中，作为账户的属性】在业务上并没有“独立”改账期的业务，或者依据数据修改的频率，从业务上来说，客户不会频繁的去修改“账期”。支付渠道以及支付计划（自动），从业务上判断是独立于账户的概念。

分析完三户模型后增加一个章节，为支持IoT业务的模型设计说明。

总结：业务模型不等同步于数据模型，数据模型就是用于数据存储而存在。其考虑的最主要的目标就是如何能够快速、高效的支持业务对数据存储的需要。个人觉的，可以有以下几个点来考虑： 1、简单，数据模型或者是表结构的设计要足够简单，简单也是高效数据的处理的基础。数据模型不同于业务模型，业务上需要考虑可变、抽象。是为了能够最高效的支撑业务的发展需要。而数据模型是最终业务数据的存储载体或约束。两者是可以不对等的。例如，在上面提到的例子中。业务上可以抽象一个Party模型，但是在物理数据模型上有必要在设计一个Party的表结构吗？我觉的是值得商榷的，设计了Party模型一方面增加了数据处理的过程，也就增加数据处理的复杂度。另一方面，在理解上。也要求具备一定的业务能力的人才能够理解数据模型的含义，包括实例化的存储数据的含义。客户表就存储客户信息，关联实体资料信息、证件信息、地址信息等。合作伙伴表就存储合作伙伴信息，关联实体资料信息、证件信息、地址信息。合作伙伴就是合作伙伴，客户就是客户。需要扩展的信息，直接通过表的主键进行关联。 2、职责单一，要求数据表所承载的功能职责单一，尽量将数据的操作封装在一定范围内。避免因为不同的业务需求操作相同的数据表。需要从业务上判断，是否需要将数据单独拆分为一个独立表。如果业务概念上是分开的，并且业务会提供独立的功能（如界面、接口）。那么就可以考虑将数据独立拆分，设计一个表。这样，业务的功能范围所需要处理的数据就会被限定在一个范围内。

思考：再拿用户来说，真的需要Subscrib表来记录信息么？

两种设计风格，我更倾向于这种。

没有用户，只有数据需要记录的客户购买产生的“订购”产品的实例数据，以及相关的数据信息。注：从最终的实际记录的数据来看，两者之间的差别并不大。因为，最终需要记录的信息就是：客户购买、订购了哪些产品。虽然概念上不同，但是最终表达的数据信息相同。扩展一下场景，如果一个客户仅仅是购买了一部手机呢？这种销售的场景，对于运营商来说，手机并不存在按周期按某种使用量收取费用的情况。分期付款从概念上，也只是将一次性需要交纳的费用分开支付。这个可以归纳到支付计划中，在账户模型中支持属于费用支付。使用用户的概念就无法表达，因为这里不存在用户。因此，就提出了客户级订购的概念。不创建用户，直接关联商品实例。 “定制”需求对模型的约束在BSS的软件领域，需求往往是千差万别的。即使是同样的业务，不同的运营商由于自身的组织结构、管理流程、国家法规、当地人民的消费习惯等等，都会导致有很大的差异。在这种情况下，数据模型往往不能很好的支持差异性的业务需求对数据存储的要求。 1、在表中预留扩展字段，在实际需求开发中明确预留字段的业务含义。 2、在定制时，可以自定义扩展表，按照业务的含义。预留扩展字段适用于在对数据扩展要求不高的场景，仅需要添加几个字段即可。需要在数据模型层上，增加业务含义的定义，例如别名。很早的概念，也是成熟的概念。在实体定义上增加字段映射即可。

产商品表亲情号码实现的方案说明商品实例+商品实例属性还是单独设计一个表来记录？判断原则： 1、实现的复杂度； 2、是否可以复用； 3、性能； 4、数据量。

大宽表技术？

从创建客户开始 BSS（Business Support System）就是电信运营商用于面向2C的客户（个人或者是企业），销售电信网络服务的支撑系统。它和现在的电商系统非常类似，但是又带有自己特殊的功能。典型的，电信网络服务（语音、短信和数据）作为商品，和普通类的商品具有明显的差别。电信服务类的商品，具有持续为客户提供服务的特点。一般来说，客户购买这类服务后，需要在运营商的网络上作相应的处理，也就是为客户开通相应的服务。在后面的章节中，会在详细介绍针对网络服务的产商品定义。订单中，针对网络服务类商品的处理。本章，我们先从创建客户资料开始。这里，直接来看客户相关的模型定义。事务数据库范式，级联or不级联。使用数据库的级联，当删除主表的某条记录时，数据库会根据级联关系，自动将关联的从表中的数据删除掉。事务在外面控制，先删除主表数据，再删除从表数据。考虑一个场景，当数据库中的数据处理的量级很大时。需要对数据库进行分库处理（分库是因为单一数据库实例的性能无法满足当前对数据库请求的处理）时，主表和从表可以使用完全不同的分库策略。例如，主表使用CustomerId作为分库策略，而从表使用id作为分库册策略。约定：只做单表级别的操作。

lottons / BSS_DEMO

基于BSS业务系统构建的思考总结 #3

章节：

模型

三户

产商品

订单

库存

技术实现

中间件J2EE的架构

如何实现

Spring＋Hibernate的崛起

J2EE标准的优点

J2EE有哪些是可以借鉴的

云平台的思考

小型化的分布式服务架构

架构设计说明

实现样例

优缺点分析

真的需要吗？

关键业务&技术实例分析

架构的目标

异步框架的设计和分析

大数据量存储的支持

可靠性如何保障

如何提升效率？

高效的开发框架能带来什么

开发框架的设计目标

开发框架应该设计的内容

前端开发

中间服务的开发

如何盈利

提升效率

影响软件产品（BSS）效率的因素

软件产品的特点&利润分析

模型