这是《从0到1写一个网站》系列第二篇文章。
这篇文章主要描述我要做的这个网站的功能，以及我对这些功能的拆分，然后使用事件风暴的方式，归纳出主要的领域模型和领域事件。
需求描述
整个网站应该分为管理端和门户端。管理端用于我自己在后台管理整个网站，包括发布文章、管理评论等等。管理端需要登录，但不需要做太复杂的权限管理，因为只有我一个用户。
门户端是给其它人用的，也就是大家现在看到的我的个人网站的样子，可以在上面看到我发布的文章，也可以对文章进行评论，对网站留言等等。
管理端
我用思维导图归纳了管理端的主要功能：
主要核心的还是文章。但我把标签和素材单独拿了出来，是想到以后网站可能会继续开发新的功能，比如类似于朋友圈、相册、电商等功能。那这样信息分类、文件素材等等能力其实是可以通用的。
除此之外，还对网站版本、公告、邮件订阅等等小功能也有一定的支持。
门户端
门户端会相对简单一些，因为很多东西都是只读的，少了很多操作。门户端全程是不需要登录的，包括留言操作。所以这里可能要注意一下安全性的问题，包括防刷和幂等。
在最初设计的时候，我认为有些文章可能是需要密码的，有些页面也可能是需要密码的，比如我们可以把求职简历放在上面。
事件风暴
我使用了事件风暴对整个需求进行了分析，试图寻找可以用于实现这些需求的领域模型、领域行为和领域事件。
我用三种颜色的便利贴来标识它们：
最终，我得到了下面9张图：
其中，页面配置是想把网站上的一些东西做成配置化的，包括一些页面的背景图和文案等，现在也实现了这个功能：
按道理说，标签、素材、密码其实也可以放在文章里面，成为文章这个聚合的一部分。但是这里单独拿了出来，是考虑到以后可能会有其它场景也会用到标签、素材、密码。
理论上来说，它们也可以成为单独的领域模型，对外提供服务。事实上很多公司也是这么做的，所谓业务中台，其实就是业务能力的复用。比如标签这个东西，它其实是一个信息管理的能力，既可以用在文章上，也可以用在商品上，还可以用在客户上。
但后来我想了一下，这样做是方便扩展了，但对于现在来说可能会加大开发成本。尤其是在找“标签”和“密码”的时候，我是非常纠结的。
于是，我砍掉了一些不那么核心的领域模型，更聚焦在核心的领域模型上面。最终剩下这么6个领域模型：
那标签和素材怎么办？
还是简单粗暴的处理方式，放在文章内部。因为其实现在也主要是文章会用到这两个东西，完全可以把它们作为文章这个领域模型的一个值对象。其实我现在线上这个版本也是这么做的：
当然了，从实现上来讲，可能底层的存储会和现在的实现有些不一样，因为之前就是在信息分类这块没做好，所以产生了“文集”、“主题”、“标签”等等一堆概念。但其实只需要标签就可以了，基于标签来做分类、搜索、推荐的功能。所以标签可能在DB层面是一个单独的表，但如何实现不是在这个阶段需要思考的，现在我们只需要关心领域模型就行了。
密码这个东西，现在看起来不是非要不可，而且想设计一个对多种资源加密的密码管理，开发成本较大，尤其是前端。所以我直接去掉了密码这个领域模型，也砍掉了与之相关的需求。以后如果有文章加密的需求，也可以作为文章的一个值对象来处理。
所谓DDD，最后一个D就是Design，没有绝对正确和标准的领域模型，只有合适的领域模型。设计总会有所权衡和取舍。在设计过程中，也会发现有些需求可能不合理或者实现成本比较大，可以做适当的调整。
没有再细分子域和限界上下文。因为目前来看，个人网站的功能还是比较简单的，没有必要再细分。真要细分的话，我觉得可以分为“文章域”、“网站管理域”和评论域，其中文章、订阅等属于文章域的，页面配置、公告、版本介绍等属于网站管理域。评论单独拿了出来，因为它是一个通用的子域，它既可以用于文章评论，也可以用于网站留言板。
为什么评论不拆开，一个是“文章评论”，一个是“留言板”？因为我认为两者其实是一个东西，都是用户在网站上留下一段话，也可以回复别人。只是评论的主体不同而已，一个是文章，一个是网站本身。所以我认为它是一个独立的领域模型。
整个网站的需求拆分、模型设计都已经搞好了，下一步需要做的就是开始搭建开发环境啦，敬请期待！
