像梦一样奔驰|谈DDD领域驱动设计和建模作者：人月神话

作者：人月神话，新浪博客同名
简介：多年SOA规划建设，私有云PaaS平台架构设计经验，长期从事一线项目实践
今天谈下领域驱动设计方面的内容，其中部分内容来源于《领域驱动设计:软件核心复杂性应对之道》书籍的读书笔记整理。
我前面谈了很多关于中台， SOA和微服务的文章，实际上你可以看到中台层对外和对前台提供的服务更多就应该是粗粒度的领域服务能力，如果中台最终只提供书籍对象的CRUD类API接口服务，那么根本就谈不上中台的共性业务服务能力下沉。
领域驱动设计概述
什么是领域驱动设计（DDD）
2004年著名建模专家Eric Evans发表了他最具影响力的书籍:《Domain-Driven Design –Tackling Complexity in the Heart of Software》(中文译名：领域驱动设计—软件核心复杂性应对之道) ，书中提出了“领域驱动设计(简称 DDD)”的概念。
领域驱动设计事实上是针对OOAD的一个扩展和延伸， DDD基于面向对象分析与设计技术，对技术架构进行了分层规划，同时对每个类进行了策略和类型的划分。
领域模型是领域驱动的核心。采用DDD的设计思想，业务逻辑不再集中在几个大型的类上，而是由大量相对小的领域对象(类)组成，这些类具备自己的状态和行为，每个类是相对完整的独立体，并与现实领域的业务对象映射。
领域模型就是由这样许多的细粒度的类组成。基于领域驱动的设计，保证了系统的可维护性、扩展性和复用性，在处理复杂业务逻辑方面有着先天的优势。
领域驱动设计的特点
【像梦一样奔驰|谈DDD领域驱动设计和建模】领域驱动的核心应用场景就是解决复杂业务的设计问题，其特点与这一核心主题息息相关：
01-分层架构与职责划分：领域驱动设计很好的遵循了关注点分离的原则，提出了成熟、清晰的分层架构。同时对领域对象进行了明确的策略和职责划分，让领域对象和现实世界中的业务形成良好的映射关系，为领域专家与开发人员搭建了沟通的桥梁。
02-复用：在领域驱动设计中，领域对象是核心，每个领域对象都是一个相对完整的内聚的业务对象描述，所以可以形成直接的复用。同时设计过程是基于领域对象而不是基于数据库的Schema ，所以整个设计也是可以复用的。
领域驱动设计的分层架构
下面我们简单介绍一下领域驱动设计的分层架构和构成要素，这部分内容在Eric Evans的书中有非常详尽的描述，想要详细了解的，最好去读原版书籍。
下面这张图是该书中著名的分层架构图，如下：
整个架构分为四层，其核心就是领域层（Domain），具体描述如下：

用户界面/展现层：负责向用户展现信息以及解释用户命令。
应用层：很薄的一层,用来协调应用的活动。它不包含业务逻辑。它不保留业务对象的状态,但它保有应用任务的进度状态。
领域层：本层包含关于领域的信息。这是业务软件的核心所在。在这里保留业务对象的状态,对业务对象和它们状态的持久化被委托给了基础设施层。
- 上一页
- 1
- 2
- 3
- 4
- 5
- 6
- 下一页