.NET云原生应用实践（二）：Sticker微服务RESTful API的实现

本章目标

1. 完成数据访问层的基本设计
2. 实现Sticker微服务的RESTful API

引言：应该使用ORM框架吗？

毋庸置疑，Sticker微服务需要访问数据库来管理“贴纸”（也就是“Sticker”），因此，以什么方式来存储数据，就是一个无法绕开的话题。如果你遵循领域驱动设计的思想，那么你可以说，保存到数据库的数据，就是“贴纸”聚合在持久化到仓储后的一种对象状态。那现在的问题是，我们需要遵循领域驱动设计的思想吗？

在目前的Sticker微服务的设计与实现中，我想暂时应该是不需要的，主要原因是，这里的业务并不复杂，至少在Sticker微服务的Bounded Context中，它主要关注Sticker对象，并且这个对象的行为也非常简单，甚至可以把它看作是一个简单的数据传输对象（DTO），其作用仅仅是以结构化的方式来保存“贴纸”的数据。你或许会有疑问，那今后如果业务扩展了，是否还是会考虑引入一些领域驱动设计的实现思路甚至是相关的设计模式？我觉得答案是：有可能，但就Sticker微服务而言，除非有比较复杂的业务功能需要实现，否则，继续保持Sticker微服务的简单轻量，或许是一个更好的选择。在差不多3年前，我总结过一篇文章：《何时使用领域驱动设计》，对于领域驱动设计相关的内容做了总结归纳，有兴趣的读者欢迎移步阅读。

所以，目前我们会从“数据传输对象”的角