戏说领域驱动设计（廿三）中的工厂模式，有何独到之处？

本文共计6219个文字，预计阅读时间需要25分钟。

在阐述实体概念的章节中，我们曾介绍过如何有效地创建实体，主要包含两种方式：工厂和构造函数。本章将工厂进行详细解释，这种实体简化使用难度较大，最终你可能无法通‘达’。

　　在讲解实体的章节中我们曾经介绍说过如何有效的创建实体，主要包括两种方式：工厂和构造函数。本章我们工厂进行一下详解，这种东西能有效的简化实体使用的难度，毕竟你无法通过Spring这种容器来管理领域对象。实际的开发过程中，工厂的使用要比书中的讲解会复杂一点，所以在本章我会对实践中遇到的一些问题以及使用什么样的模式去应对给出一些建议。

一、工厂的作用

　　学习过设计模式的人都应该知道“工厂模式”，尤其是其中的“简单工厂”，感觉就没什么可学的，太简单了。但在DDD中，工厂却比较常用，不过也正像书上说的一样，其实算不上一等公民，毕竟其承担的责任只是实体的创建，有点偏技术。但反过来说，少了这么一个东西还真不行，有些实体的创建起来很费劲，大部分情况下只有实体设计人能完全搞定，出现了知识垄断的情况。可是在真实的工作中，我们需要团队协作，也会出现人员更迭的情况，出现这种垄断并不是什么好事儿。此外，作为设计者，让自己研发出来的东西特别难以使用，这本身其实是失败的。看看Spring框架，你就知道人家工程师的牛掰之处了，咱不管其内部如何复杂，你就告诉我使用起来是不是很方便吧？我这里有个小经验与大家分享：不论是做后台的代码还是前端的功能，都把自己假设成为用户，你就会在设计过程中自然而然的考虑易用性和安全性了。当然，也不排除有些不愿意思考的人，不过是自废前程而矣。将自己当成用户还有另外一个好处：之所以叫用户，就代表你不能对他做任何假设，只要你提供出去功能就代表是可用的，把自己当成用户正好可以检验代码中是否存在不妥之处。