做任何一个软件系统，都是有原因的，都是要解决特定的问题。
通过问题，我们就知道了我们需要一个什么样的系统，这个系统解决了什么样的问题。
两个概念：
“问题空间（Problem Space）”和“解决方案空间（Solution Space）”
问题空间，就是当前环境下业务所面临的一系列问题和背后的需求，它属于产品规划阶段，通常是业务或产品领域专家主导进行问题需求收集描述和分析。
解决方案空间，则是针对问题空间的解决方案，它思考的是如何设计实现软件系统以解决这些问题，它属于工程设计实施阶段，通常是技术专家主导的解决方案设计和实现。
在问题空间里，主要是找出某个业务面临的挑战及其相关需求场景用例分析，而解决方案空间里，则通过具体的技术工具手段来进行设计实现。互联网软件从业人员容易理解的一个映射转化过程。
两个概念：
领域（Domain） 和 领域模型（Domain Model）也叫业务对象模型
“领域”相对于软件系统来说，就是系统要解决的现实问题。因此也可以简单理解一个领域就对应一个问题空间，是一个特定范围边界内的业务需求的总和。
“领域模型”则是针对特定领域里的关键事物及其关系的可视化表现。它属于“解决方案空间”，是为了准确定义需要解决问题而构造的抽象模型，为软件系统的构建目标统一认知，是业务功能场景在软件系统里的映射转化。
领域模型驱动设计（DDD:Domain-Driven Design）
经典分层架构
- 将领域模型相关的代码集中到一个层中，把它从用户界面、应用和基础设施代码中分隔开来
- 释放领域对象的显示自己、保存自己、管理应用任务等职责，让它专注于展现领域模型
- 复杂的程序切分成层
- 层中采用内聚的设计
- 层仅依赖于它底下的那层
架构概述
详细架构
- 实体（Entity）
-
实体就是领域中需要唯一标识的领域概念。实体有生命周期，实体从被创建后可能会被持久化到数据库。
- 值对象（Value Object）
在领域中，并不是没一个事物都必须有一个唯一标识，也就是说我们不关心对象是哪个，而只关心对象是什么。
- 领域服务（Domain Service）
领域服务是以动词开头来命名的，需要强调的是领域服务是无状态的，它存在的意义就是协调领域对象共完成某个操作，所有的状态还是都保存在相应的领域对象中。
领域服务可以避免领域逻辑泄露到应用层。引入领域服务可以有效的防治领域层的逻辑泄露到应用层，通过调用领域服务提供的简单易懂但意义明确的接口。
- 模块
- 聚合
- 工厂（Factory）
DDD中的工厂也是一种体现封装思想的模式。DDD中引入工厂模式的原因是：有时创建一个领域对象是一件比较复杂的事情，不仅仅是简单的new操作。客户传递给工厂一些简单的参数，然后工厂可以在内部创建出一个复杂的领域对象然后返回给客户，简单的调用领域工厂创建出期望的对象。
- 资源库 或 仓储（Repository）
仓储分为仓储定义部分和仓储实现部分，在领域模型中定义仓储的接口，从某个类似集合的地方根据某个条件获取一个或一些对象。根据项目中查询的灵活度要求来选择适合的仓储查询接口设计。
思考总结
领域建模不是面向技术的一种纯软件设计方法，它是一种思维方式，我们采用它来搭建领域模型。
它体现了系统的核心价值，及能解决的问题及解决的程度。
扫一扫
1750
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
