当越来越多的人，想通过取巧的方式找到捷径来拿Offer。那么这条线就会被不断的拉齐，直到越来越多的人都成了八股和刷题高手后，招聘的方式也会改变。—— 面试官不再直接问八股，而是从项目中提问，反向映射出技术和算法问题。
一、项目背景
这里以《Lottery 抽奖系统 - 基于领域驱动设计的四层架构实践》为例，之所以选择这样一个项目开发，是抽奖营销活动类系统可以适应的场景更全面，例如；电商、出行、外卖、旅游、汽车等，在促活、留存、拉新上，都可以使用抽奖系统。因为抽奖系统是工具系统，可以挂到任何其他符合场景的系统上来讲解。而且抽奖系统的架构、设计、实现都较为复杂，有东西可以聊，属于尖刀队。类似 Java 中的 HashMap 随时可以拿出来刚一下。
所以抽奖系统不存在说：“你们组多少人都做抽奖”，因为所有场景，只要符合就会有抽奖和活动，如果一个公司的产品没有营销业务这条线，那么一种是场景不符合，另外一种是压根没这个体量。所以只要你把抽奖合理的放到一个系统下，串联好你的话术能自圆其说，之后你就可以用抽奖去面试了。
二、简历：项目经验
-
项目名称：营销活动平台 – Lottery 微服务抽奖系统
-
系统架构：以 DDD 领域驱动设计开发，微服务拆分的分布式系统架构
-
核心技术：SpringBoot、Mybatis、Dubbo、MQ、MySQL、XDB-Router、ES、ZK
-
项目描述：Lottery 抽奖系统，是营销活动平台中的一个重要微服务，用于满足C端人群拉新、促活、留存的系统。系统根据微服务的界限上下文，运用抽象、分治和 DDD 知识，拆解服务边界、凝练领域服务功能。以围绕抽奖服务，解耦功能流程，建设领域服务，包括：规则引擎、抽奖策略、活动玩法、奖品发放等。来满足业务产品快速迭代上线的诉求，减低研发持续投入成本，提升交付效率。
-
我的职责：
-
构建以 DDD 分层结构的处理方式，搭建整个抽奖系统架构。
-
运用设计原则和工厂、代理、模板、组合、策略等设计模式的综合使用，搭建和开发方便维护和易于迭代的系统工程。
-
鉴于系统内有较多的规则策略过滤，包括：准入、人群、风控、A/BTest等诉求，以适合系统规模可快速开发和使用的方式，搭建去中心化的量化人群规则引擎组件，通过业务诉求对 Logic 的扩展和内置引擎执行器的使用，完成自由组合的人群过滤服务。降低共性功能重复开发所带来的成本问题，提供研发效率。
-
应实际秒杀峰值场景 TPS 2000 ~ 3000 的诉求，开发统一路由组件，不仅可以满足差异化不同字段的分库和分表组合，以及 Redis 库存分片和秒杀滑动库存分块，开发统一路由 XDB-Router 的 SpringBoot Starter 技术组件。此套组件经历数次大促活动场景，支持横向扩展，可以满足业务规模的快速增长。
-
涉及到面试可能会问到的问题，请阅读：年薪50万，项目经验这么写（下）
