在一些小的初创型公司里面，一般一个前端工作人员要维护编写多个业务方向的代码。包括
活动宣传页（主要CSS3， canvas）
mobile主战／分享页 （主要webkit内核， flexbox，微信sdk）
pc主页 （主要考虑IE浏览器兼容性，基本布局）
后台系统 （主要考虑快速开发，快速成型）
一般来说在小公司这些东西可能是一个人在编写并管理的，那应该怎样去考虑整个项目结构呢。
按照常理来说，应该没个项目单独去管理代码，但是项目之间也是有可能会用到同样的模块的，样式也有可能会用到同样的一份。需要去抽离这一部分可能公共的代码？
特别混乱，求指点迷津
其实，你上面描述的，有的公司就是干这个的，专门帮人做这方面的活动。其实HTML 5刚开始的时候，我也考虑过，尝试做这方面的活动，可惜我设计不行，所以最终搁置。
之所以，提到这个-有专门的公司处理这个。想说的是，一般的公司会涉及到这部分内容，但是业务分离，肯定不会像他们那样专业。
还有就是，抛开具体业务来说项目结构(个人理解为架构)，都是不合理的，所以，要根据自己公司的业务来。
其实，你已经梳理出来了几个部分。
比如公司有A业务，B业务，A业务会涉及到这样的活动，B业务也会涉及到这样的流程。可以考虑将这样的活动抽离为C业务，专门处理活动。
问题就变成了，如何针对C业务具体处理！
主要包含，两个部分，前端和后端，前端部分抽离相对容易一些，无非是一些常用的资源文件放在一起而已(包括抽象常见的活动处理脚本)。
后端的抽离，我想让题主困惑的是，涉及到A和B的业务逻辑，我是放在A呢，还是B呢，还是C？
我个人的观点是，如果和A，B依赖性很强，比如需要调用其中的相关模块，那么处理逻辑就最好放在对应的业务中，在C中调用A，B提供的接口就可以了。
C还是偏向于活动相关的处理，而非具体业务的处理。当然，在处理活动的过程中，也会涉及到C自己的业务。
比如，经常会处理一些抽奖的活动，那么涉及到的这部分业务与A和B的关系都不到，很可能部分数据是来自于A或者B，但是具体活动的业务还是在C完成的。
你提到的第4点，后台系统，这部分最好放在最后来处理，如果公司类似的活动的个性化不是很强，而且发布活动比较频繁，这部分相对来说还好处理，也有必要。如果公司的活动个性化比较强，今天是这样，明天是那样，你会发现还不如没有这部分。
其实，目前很多公司提供的在线制作活动的部分，其实就类似于你这里的后台系统。你最好去看几个常用的，这里就不推荐了。
如果你发现，他们在线制作的活动，不能满足贵公司的需求，那么你得问自己我们公司是否有这个时间和经历来处理这部分内容(别人是专业的，我们是业余的)。
处理这部分的时候，已经不是你一个人的事了，最好同你们的活动发起方，UI设计之类的交流一下，还有就是到网上更多的了解这方面。
先抽象出实体，然后再根据实体和业务划分大模块，之后再根据单一职责原则等七项原则设计合理的业务层，单一职责很重要，最后controller层是按视图设计还是按restful设计就随意了，理清业务逻辑，根据单一职责原则设计业务层很重要，当然实体设计的好坏也十分重要，以上是我做后端的浅薄经验…
表示经验不丰富, 我的话会优先考虑几个方面的问题,
重用的代码是否足够明确, 明确到可以拆分出来
模块化方案是否强大, 保证拆分模块之后不会遇到奇怪的问题
未来的业务能否因为拆分模块而获益
实际项目当中判断拆分模块是否合适有点难, 建议还是根据项目开发需要自己判断.