现如今，很多企业既有线上电商分销平台，也有线下实体门店分销渠道包括直营店、加盟店，不少企业还有呼叫中心进行电话营销。这么多的分销渠道如果数据不同步，信息不透明，管理不到位，就很容易导致决策失误或者直接影响销售。
于是很多企业在寻求可以同时高效管理线上销售和线下销售的一体化解决方案。具体来讲就是可以把线上的业务，线下实体门店的业务以及呼叫中心的业务进行统一管理包括销售、订单、仓库、会员、积分、促销活动、售后、采购、财务等一体化管理。
企业同时希望线上线下的数据能够完全融合，线上线下的数据能够实时互通，如会员积分管理，积分应该实时反映会员在线上线下各种活动所产生的积分变化，会员在实体店购物，会员在电商平台购物，会员在积分商城兑换礼品，这些活动所产生的一切积分变化，都应该实时的反应在同一个会员积分管理系统上。而不是线下有一套积分系统，线上又有另外一套积分系统，数据互相分离、互不相干。
企业还希望各大平台的订单，包括线下实体店的订单，能够集中在一个平台进行批量处理，包括订单的审核、拆分合并、批量打单、发货配送，并且企业能够根据订单的收货地址、仓库具体情况进行就近配送，或上门自提实现020营销功能。而不是像现在这样，管理员拥有多个平台的登陆账号，处理各大平台的订单要用不同的账号登陆不同的平台，费时又费力。
一套靠谱的全渠道会员积分系统，还必须提供强大的后台管理功能， 能够随时追踪集团、分公司、分部分店的采购，产品库存，销售订单，财务以及整体运营状况。所有的数据实时更新，自动核算，并且能够查询到数据的来龙去脉，所有的数据能够实时汇总，并尽量只需要通过系统的一个页面即可查询到，且可通过手机端查询，方便领导随时掌握运营状况，并及时响应调整市场。
我们在很多情况下，可能都是某种组织的会员，如健身、游泳馆、超市、美容店等其他连锁店，这些针对会员的管理和消费管理，从而提供给会员更多的优惠，一般通过积分的方式实现。本文主要从一个开发者的角度，对会员系统进行的设计开发进行剖析，希望能与大家一起探讨，实现更多的思想碰撞。
如果系统是在一个店铺使用的，那么使用单机版本的操作模式即可，如可以使用Winform + SQLite/Access方式，实现数据的访问，并且方便软件复制和备份工作，如果需要性能好一点或者数据更加安全一点，可以采用独立的数据库方式，如采用一个独立的机器部署SqlServer数据库或者Mysql数据库，Oracle数据库就没太大必要了。
如果系统是在一系列连锁店中使用的，那么可以采用Winform+WCF服务方式，实现数据的分布式访问方式，这样数据就不会保存在本地，和B/S通过浏览器的方式很类似，但是Winform客户端能提供更丰富的界面体验效果。当然，我们每一家的连锁店就需要能够上网，随时进行数据的交换处理。
还有一种方式，是离线式的服务，就是弥补第二种方式在断开网络的时候不能工作的缺点，这种方式即使在网络断开，也能照常运营，网络通畅的时候，通过手工进行数据的提交就可以了。由于现在网络一般比较方便，所以这种方式一般采用的不多，只在特殊情况下采用。
1、系统用例的设计
我们知道，会员管理的主要目的就是以会员为中心，实现相关数据的管理。会员管理包括有会员本身的信息管理、会员收费管理、积分管理(积分增减、积分兑换、积分转账)、挂失管理、换卡管理、余额转账、商品管理、消费管理等等，围绕着会员管理展开，通过多个职能操作，实现相关数据的录入和管理。
2、系统数据库设计
数据库的设计，也主要是围绕着会员信息进行的，会员信息是作为所有会员相关记录的外键引用。为了避免数据库表的阅读困难，会员管理的相关表，使用“MS_”前缀声明。
除了以下的表外，还包括了会员的打折设置信息，积分奖励设置，以及用于会员消费的商品信息，及会员消费的记录信息(包括消费主表和明细表记录)。
为了篇幅的介绍，我主要列出会员的主表信息作为讨论参考。
表主要使用字符型的ID作为表的主键，保存的时候，ID自动使用GUID作为数据存储，由于考虑了可能多个连锁店的情况，因此，我们需要增加一个Creator, CreateTime, Editor,EditTime, Dept_ID, Company_ID的通用字段，方便存储用户的相关表记录信息，这样我们在数据过滤以及报表查询的时候，会方便很多。
3、系统模块化设计
当然会员的信息还可以扩展更多，我们一般是以一个通用的会员管理来实现这个模块，从而可以在整个大系统中进行整合和使用。而一般我们都有自己的平台模块积累，在业务层只需要整合现有的一些底层模块作为支持，业务系统我们独立开发即可，大概的构造如下所示。
当然，我们随着系统的开发，我们可能需要整合两个以上的系统(或者底层业务模块)到一个大系统里面，这种要求就需要我们所有的系统模块，都可以通过松耦合、插件化整合的方式实现使用的。
