企业🤖AI智能体构建引擎,智能编排和调试,一键部署,支持私有化部署方案 广告
# [.NET领域驱动设计实战系列]专题十一:.NET 领域驱动设计实战系列总结 ## 一、引用 其实在去年本人已经看过很多关于领域驱动设计的书籍了,包括Microsoft .NET企业级应用框架设计、领域驱动设计C# 2008实现、领域驱动设计:软件核心复杂性应对之道、实现领域驱动设计和Asp.net 设计模式等书,但是去年的学习仅仅限制于看书,当时看下来感觉,领域驱动设计并没有那么难,并且感觉有些领域驱动设计的内容并没有好的,反而觉得有点华而不实的感觉,所以去年也就放弃了领域驱动设计系列的分享了,但是到今年,在博客园看到还是有很多人写领域驱动的文章,以及介绍了领域驱动设计相关的好处,这时候我就想,领域驱动设计真有这么好吗?但是我并不觉得好了,这时候就想是不是我没有实战没有深刻的感受呢?因此我在今年3月份的时候又重拾领域驱动设计,打算分享一系列关于领域驱动设计实现的文章,所以也就有了这个系列。 ## 二、本系列所有专题目录 在刚开始打算写的时候,本以为对领域驱动设计相关理论知识掌握的不错,但当真正打算写的时候,发现之前的知识储备差不多忘的差不多了,无奈下只有重新再拿起书本来温习一遍,不过这次温习很快,因为之前都已经看过一篇。这里分享出来就是想告诉大家,没有真正实践过的东西是很容易忘记的,这时更加坚定了我要写这一系列的文章了。这个初衷也是我一直坚持写这个系列的动力。现在这个系列也告一段落了,从中我确实体会了领域驱动设计的美妙之处,以及现在软件设计的发展和改变。下面是本系列中所有专题的一个目录,为了帮助更好地收藏和自己进行索引,关于实践下来的体会将在下一部分分享给大家。 [[.NET领域驱动设计实战系列]专题一:前期准备之EF CodeFirst](http://www.cnblogs.com/zhili/p/EFCodeFirst.html) [[.NET领域驱动设计实战系列]专题二:结合领域驱动设计的面向服务架构来搭建网上书店](http://www.cnblogs.com/zhili/p/OnlineStorewithDDD.html) [[.NET领域驱动设计实战系列]专题三:前期准备之规约模式(Specification Pattern)](http://www.cnblogs.com/zhili/p/SpecificationPattern.html) [[.NET领域驱动设计实战系列]专题四:前期准备之工作单元模式(Unit Of Work)](http://www.cnblogs.com/zhili/p/UnitOfWork.html) [[.NET领域驱动设计实战系列]专题五:网上书店规约模式、工作单元模式的引入以及购物车的实现](http://www.cnblogs.com/zhili/p/OnlineStore_Second.html) [[.NET领域驱动设计实战系列]专题六:DDD实践案例:网上书店订单功能的实现](http://www.cnblogs.com/zhili/p/OnlineStoreImplementOrder.html) [[.NET领域驱动设计实战系列]专题七:DDD实践案例:引入事件驱动与中间件机制来实现后台管理功能](http://www.cnblogs.com/zhili/p/OnlineStoreImplementManager.html) [[.NET领域驱动设计实战系列]专题八:DDD案例:网上书店分布式消息队列和分布式缓存的实现](http://www.cnblogs.com/zhili/p/OnlineStoreImplementDistribution.html) [[.NET领域驱动设计实战系列]专题九:DDD案例:网上书店AOP和站点地图的实现](http://www.cnblogs.com/zhili/p/OnlineStoreImplementAOP.html) [[.NET领域驱动设计实战系列]专题十:DDD扩展内容:全面剖析CQRS模式实现](http://www.cnblogs.com/zhili/p/CQRSDemo.html) ## 三、总结 通过对领域驱动设计的实践,本人对领域驱动设计的有点和缺点都有了一个清晰的认识。并不是所有软件都适合应用领域驱动来实现的,例如在一些公司还是用三层框架来进行软件的开发,这样并没有什么不好,针对一些业务逻辑简单和后期需求变更不大的软件,完全可以使用三层框架来进行开发,因为三层框架尽管各层之间的依赖关系比较大,不利于扩展。但其好处就是简单,快捷。对于一些小型项目用三层框架是极好的。但对于一些大型项目来说,三层框架可能就不怎么适合了,尤其是大型网站项目。这时候就可以考虑使用领域驱动设计,领域驱动设计推崇的富领域模型,即将相关实体的业务逻辑放在领域实体里面。领域驱动设计思想分层结构更细,使得各层之间的依赖降低,通过引入依赖注入框架拉进入达到低耦合,高内聚原则。并且通过仓储模式,可以使得针对其他数据库的存储也可以很方便的进行扩展。采用领域驱动设计也可以更多实施测试驱动开发,早在以前的项目,哪里会有单元测试这个东西啊。 通过这个系列最深刻的感受,除了对领域驱动设计有了更进一步的认识外,还有一点更深刻的感受就是做软件的一定要把自己学到的内容实践起来,并且通过博文或其他方式进行总结,这样才能更好的积累。尽管通过博文的方式不经常用一样会忘记,但是很多东西你总结了就是和没总结的不一样,总结了可以对知识有一个系统的梳理,这样可以让你深刻理解知识点,尽管忘记了,它也是被记录在大脑的某个角度,当重新遇到问题时,你完全可以通过自己写的博文重新找回来,并且找回来的认识并不会比之前的理解少,可能更加多,但是不总结的话,那种忘记可能就是真的忘记了,等于没看一样。所以,对于做软件来说,真需要多实践。所以,还是奉劝大家可以多总结,多实践,抛下浮躁的心态,想做好技术,需要的静下心来专研和实践。最近,刚接触的一个项目用到了一个一些非关系数据的内容。所以接下来,我将会新开一个非关系数据库的系列来进行总结自己这段时间里的经历。其中包括Mongodb、Redis等非关系数据库的相关内容。 最后附上,所有专题的完整DDD实践案例下载地址: **DDD实践案例下载地址:[DDD实践案例:网上书店](https://github.com/lizhi5753186/OnlineStore)**