[实现领域模型.docxVIP

DDD入门领域模型是关于某个特定业务领域的软件模型。通常，领域模型通过对象模型来实现，这些对象同时包含了数据和行为，并且表达了准确的业务含义。领域模型的优点使领域专家和开发人员在一起工作，形成一个紧密的团队，使代码就像是领域专家自己编写的一样。可以帮助领域专家、开发人员互相提高业务水平保证对业务知识的集中，使业务知识不必集中于少数人手中使领域专家与开发人员之间不存在“翻译”语言，大家用同一种语言在交流，不存在沟通的障碍。清晰的系统结构，利用限界上下文可以更好的划分系统模型边界。DDD的战略设计可以帮助我们定义不同团队之间的组织关系，并在这些关系有可能导致项目失败的时候提供预警。还可以清楚的划分不同的系统和业务关注点。贫血模型只有get、set方法与属性而没有其他行为方法的对象被称之为贫血对象。贫血模型只是将关系数据库中的模型映射到了对象上而已。贫血模型造成系统的维护变得异常困难。贫血对象是现在的Web框架和持久化框架的流行造成的。比如Hibernate和Struts2传递对象拥有get、set方法。不过现在Hibernate在持久化时已经不需要get、set方法了。如何做DDD通用语言和限界上下文是DDD的两大支柱，并且是相辅相成的。通用语言是团队内的领域专家和开发人员共同创建的共用语言。通用语言和限界上下文存在一对一的关系，通用语言在多个限界上下文中有可能存在不一样的意思。只有在一个限界上下文中讨论此通用语言才有意义。通用语言发现过程利用物理模型图和概念模型图，并标以名字和行为。这些设计图包含了系统建模的某方面，即使我们在项目中应用了UML也还是需要这两个设计图来完成团队之间的讨论。利用术语表和文档领域、子域和限界上下文从广义上来讲，领域就是一个组织所做的事情以及其中所包含的一切。在一个好的限界上下文中，每一个术语应该仅表示一种领域概念。一个子域对应一个限界上下文这是基本标准，我们尽量不要让子域和限界上下文相交我们工作的关注点应该放在核心域上。战略设计在设计开发时不应该一上来就去关注实体、值对象，而应该用更广阔的视野，先去考虑战略设计(划分子域、限界上下文)再去考虑战术设计。在划分子域与限界上下文时一定不能都放在一个域或者一个上下文中，因为那样会导致一个大而全的大泥球架构，会导致系统以后很难进行维护、分布式部署。对于领域内的内容不要按照表结构去分析，而要利用四色原型去分析。理解限界上下文限界上下文就是一个显示的边界(语义上的边界，我们目前用框图来表示限界上下文，但框图并不是限界上下文本身)，领域模型则位于边界之内。在边界内，通用语言中的所有术语和词组都有特定的含义（如果再不同的上下文内，看到了相同的对象，那么通常认为此模型是错误的，除非这些上下文使用了共享内核），而模型需要准确地反映通用语言。一个限界上下文可以包括领域模型(主要公民)、模块、聚合、领域服务、领域事件、应用服务、面向服务的组件（Webservice/Rest/Jms）、数据库的Schema等。我们应该拒绝使用智能UI(界面显示、事务、逻辑混合在一起)。也不需要利用用户界面中对领域进行建模，这样会导致贫血对象。设计限界上下文应该注意的东西：不要采用架构来指导设计开发上下文，应该用通用语言不要根据任务的分配来拆分上下文，尽量保证一个团队一个上下文，尽量少使用共享内核使用模块可以避免创建一些微小的上下文。上下文映射图一个项目的上下文映射图可以画一个简单的框图来表示两个或多个限界上下文之间的映射关系。尽早的绘制上下文映射图，可以迫使你仔细思考你的项目和你所依赖项目之间的关系。上下文映射图并不是一种企业架构，也不是系统拓扑图，他是一种更高层次的架构，上下文映射图展现了一种上下文之间的组织动态能力。常用的集成模式：开放主机服务：该模式一般通过REST实现，我们一般将开放主机服务看成是远程方法调用的API。发布语言：在使用REST服务时，发布语言用来表示领域概念，此时可以使用XML和JSON防腐层：在使用REST时，客户端的领域服务奖访问远程的开放主机服务，远程服务器以发布语言的形式返回，下游的防腐层将返回内容翻译成本地上下文中的领域对象。架构分层架构分层架构分为两种：在严格分层架构中，某层只能与直接位于其下方的层发生耦合，而松散分层架构则允许任意上方层与任意下方层发生耦合。由于用户界面层和应用服务通常需要与基础设施层打交道，所以大多数的分层架构属于松散分层架构。传统-松散分层架构用户界面只用于处理用户显示和用户请求，而不应该包含领域或者业务逻辑，有人说既然用户界面要对用户的输入进行验证，那么就应该包含业务逻辑。其实，用户界面进行的验证和对领域模型进行的验证是不同的，所以用户界面不应该包含业务逻辑。但是如果用户界面使用了领域模型中的对象，此时的领域对象也仅应该用于数据的渲染