领域就像您的应用程序的一个组件。但不是针对 UI，而是针对您的业务逻辑。
所有相关的东西都封装在域中。
一个域可以拥有下面列出的任意数量的资源。
- 域状态：您要存储在域中的状态。
- 域实体：要存储在域中的实体。实体必须具有唯一标识符作为键。
- 领域事件：识别领域中发生的事情。
- 域命令：更新状态/实体或发出事件或什么都不做。
- 域查询：查询状态/实体或派生另一个查询。
- Domain Effects : 执行副作用并发送命令或事件的 observable。
对于任何域，只有domain-query, domain-command,domain-event可以暴露给外部。
domain-state并且domain-entity不暴露在外面，也不能在域外直接触摸。
对于任何域的消费者。
- 读取状态或实体的唯一方法是通过domain-query防止无效读取。
- 更新状态或实体的唯一方法是通过domain-command防止无效更新。
特征
- DDD 原则
- CQRS 架构
- 事件驱动架构
- 增量更新
- 反应式编程
- 不可变状态
- 类型友好的 API
- 框架无关（React/Vue 官方支持）
- SSR 支持
Remesh 支持一种类似于 react-hooks 的机制，用于在域之间重用难以通过类归档的逻辑。
Entity的概念在Remesh中有着自己的意义，它是在Remesh世界的有界上下文中。所以没有聚合根和ValueObject。
Remesh 中的战术 DDD实现不是使用OOP，而是使用函数式编程凡是。
作者的话：
DDD实践可以分为两部分，一是知识获取，一是代码实现。
知识获取部分，独立于代码实现，关系到开发者与领域专家的密切沟通与协作。
另一方面，代码实现部分需要准确反映领域知识或领域规则。这不是随机编写的代码可以满足的要求。我们所谓的DDD框架，就是为了帮助开发者更好的达到将领域规则与代码拟合的目的。
当我们说 DDD 框架时，它是一个编程领域概念，服务于 DDD 实践的代码实现部分。
至于 Remesh 如何在前端开发中服务于上述目的，请尝试使用 Remesh 开发您的前端应用程序，最好具有足够的复杂性，以能够证明使用 DDD 思想管理复杂性的目的。