2.业务中台采用领域驱动设计（DDD），在其上构建业务能力SAAS，持续不断进行迭代演进。
3.平台化定位，进行了业务隔离设计，方便一套系统支撑不同玩法的业务类型和便于定制化扩展。
4.前后端分离，通过服务接入层进行路由适配转发。
5.天然的分库分表，消息解耦和分布式缓存设计，支持弹性扩容，以支持大数据高并发场景。
接下来将分别介绍每个部分。
中台部分在逻辑上分成了基础能力和平台产品两层，这样做的好处是，基础能力层聚焦于稳定收敛的业务模型和基础服务本身，不会随着业务和前台产品的调整发生变化，可以简单理解为业务模型的DAO。平台产品层则专注于通过流程编排类的技术手段，将基础能力构建成业务的解决方案，解决共性和个性化的问题。我们将以交易的设计为例来说明这个分层理念。通过对电商交易业务的深入分析，
可以确定几乎所有的交易都会涉及下图中所有的领域（库存，优惠，价格…），而单看每个域，玩法都是很少变化的，将这些域的基础能力完全可以沉淀下来形成原子的基础能力，通过扩展点方式应对将来特殊的场景个性化扩展。
平台产品层为了应对不同的交易场景（一口价，拍卖，货到付款，预售…）将原子的基础能力编排成满足不同场景的解决方案，以服务的方式透出出去。
服务接入层是连接前台产品和中台产品层的纽带,实质就是之前的web应用，不同的是现在前后端分离后，只包含java代码，使用springBootweb。做参数转换，路由分发，调用中台服务，结果封装。这块需要做好前后端的交互规范，请求路由映射规范，web工程目录结构，负载均衡方案，跨越问题和安全问题，
后续会有专题详细介绍这块。
沉淀和抽象出通用独立的公共基础组件，这些组件在服务本项目，本团队的同时，可以开源出去服务更多的人；抽几个非常重要的组件讲一下这么做的目的。
数据访问组件：抽象封装分库分表访问，读写分离，主备切换。
消息中间件组件：这块的选择非常多，就开源的就有activeMQ,RabbitMQ,RocketMQ,Kafka等等,再加上阿里云，AWS,腾讯云等提供的和对应的云版本，会非常多，如果不对这块做封装，对其上应用做透明化处理，后期做这块的适配调整就会非常痛苦，特别是这套系统会在不同环境中进行部署时。
为了适应小程序，社交电商这样的热点，加上有这么优秀的一套电商中台系统，不搞出点有么有样的电商前台产品，不是很没有道理，为此想破脑袋，我们把电商和送礼结合了起来，做了“礼尚往来”的小程序，下面是产品的截图。
对电商这类在线交易系统，流量会随着运营活动的波动非常大，特别是到了双11这类大活动的时候，流量的峰值会是平时的几十~几百倍，一些接口会放大的更大；核心系统的系统指标，流量，接口调用量和rt,以及限流和异常的监控就显得非常重要了。在几年之前，只有BAT几个大的公司有能力在这方面做的不错，随着全民参与的这种大型促销活动推动技术的进步，以及开源社区和一些大厂将类似方案回馈到开源社区，目前一个小的技术团队做好这块也没有什么难度了。现将我们用到的框架做个简单的介绍，更多细节请参考官方文档。
sentinel:是面向分布式服务架构的轻量级流量控制产品，主要以流量为切入点，从流量控制、熔断降级、系统负载保护等多个维度来帮助您保护服务的稳定性。该系统已经过阿里内部双11多年的验证，稳定性和可靠性非常不错，已于最近开源。
dubbokeeper：dubbo的官方监控dubbo-monitor-simple在性能上表现非常不好，经常卡死，对比了几个成熟的框架后，最终确定使用dubbokeeper.dubbokeeper社区版dubboadmin,包括了应用管理，动态配置，统计信息，服务监控和zk信息查看功能。
pinpoint:现在基于微服务的架构，一个请求从用户发起到响应，中间调用链路非常长，跨越数十个系统很正常，并且路径非常多，要定位一个比较耗时的响应，不利用工具，是非常低效的。Pinpoint这样的工具就是为处理这个问题出现的，Pinpoint的优点是对代码零侵入，运用JavaAgent字节码增强技术，追踪每个请求的完整调用链路。
Telegraf+influxDB+Grafana：主要用来实现业务数据的实时监控方案，如交易额的不正常波动，订单量的突然下跌等。Telegraf是收集数据的代理程序，可以根据业务需要添加插件扩展服务，收集到的数据写入分布式时序数据库influxDB,再通过grafana可视化的展示出来。