DDD与Spring Data MongoDB
IoC注解主要有两大类：
(1)声明Bean的注解：告诉别人自己是bean；个组件对象，把自己声明成bean。
(2)注入Bean的注解：在一个bean中注入另外一个bean，有依赖关系的Bean相互注入的注解。
声明式（1）告诉别人自己是bean
声明Bean的注解如下。实际上，后3个注解的功能和第1个一致。但如果我们能够明确bean的层次，最好用后3种，这样代码可读性比较高。
@Controller – indicates that the class serves the role of a controller, and detects @RequestMapping annotations within the class
@Service – indicates that the class holds business logic and calls methods in the repository layer
@Repository – indicates that the class defines a data repository; its job is to catch platform-specific exceptions and re-throw them as one of Spring’s unified unchecked exceptions
该注解用于标注一个控制器组件类（Spring MVC的Controller），其功能与@Component()相同。
注解2-4，是与MVC中的架构来对应的。
=======================================================
以下这部分转载：https://zhuanlan.zhihu.com/p/29035930
@Controller, @Service, @Component, @Repository
其中@Component是一种通用名称，泛指任意可以通过Spring来管理的组件，@Controller, @Service, @Repository则是一种特定的组件，通常用来表示某种特定场合下的组件，@Repository用来表示仓库（数据层，DAO），并且Spring 框架会根据这种应用场景做些定制，比如@Repository同时具备了自动化的异常转换。类似的， @Service则用来表示服务层相关的类， @Controller则用来表示展示层（presentation）的类。
那Service是什么呢？
Service 表示了在软件分层设计中的Service层，用来连结数据层（DAO）和展示层（Presentation）。
为什么要在DAO层上加一层Service呢？
在某些简单的应用中，DAO层的功能和Service的功能很接近，甚至初学者会觉得Service层做的事情和DAO层都一样，那为啥还要将Service层单独拿出来做一遍呢？而且，很多场景下，Service层和DAO层同时存在，往往会增加代码复杂度，编码工作量，写的不好甚至会造成混淆。
通常来说，DAO层应尽力保持简单，其功能仅仅是提供了数据库的连接，以及最简单的增删改查（Crud），有时还需要做些抽象，以此来连接使用不同技术的数据库。除此之外，任何业务相关的操作都应该放到Service层，即Service层用来编写业务逻辑，即操作从DAO层读取的数据，或者将处理好的数据给DAO层，当使用Domain Driven Design时， 这两个类通常会放到同一个Domain（包）中，即便在简单的应用中，他们的代码可能极其类似，但是仍应该分别对待。而不是跳过service层（service）直接去使用DAO层（repository）来放业务逻辑数据。
这样带来的好处带来更好的模块化结构，有便于后期的扩展和维护，比如更换数据库实现时，我们仅仅需要处理DAO层的内容就好了。并且，当业务逻辑比较复杂的时候，比如有很多报告要出的时候，Service层就提供了一个很好的空间来实现这些代码。其次，在web应用开发中，使用Service层可以将web类的活动限制在controller中，这样可以独立的测试service层
另外，还有一种情况，就是当应用极其复杂，需要同时使用多种数据库时，将从DAO中获取数据的动作放到一起可以减少数据库的操作，并且可以保证数据的一致性。同时Service可以嵌套，因此如果需要使用不同的数据库时，可以在service中指定。
在Service中也可以放一些通知类的操作，比如发送邮件等，这样也可以保持controller的整洁。
还有一个潜在的好处是安全性，当使用service层包裹DAO层后，数据库的链接是被service层保护起来的，这样如果客户端被某种情况攻陷，其只能使用service层提供的有限数据，而无法直接攻击数据库
另外，在Spring 框架中，security也是在Service层实现的。根据上面的逻辑，我们在实际开发中，应该不去实现自己的DAO层，而是使用Spring Data JPA，因为Spring Data JPA已经实现了DAO层。
这种写法常见的问题有啥？
最常见的写法（或者是错误的写法）有以下几种
1、面向领域的模型对象仅仅用来存储应用中的数据，换句话说，是不太符合domain model 设计的
2、处理模型数据的业务逻辑分散在service层
3、每个entity都有对应的service类
这样写的原因很大程度来源于上面的分层理论，我们确实将应用分成了展示层（web layer），服务层（service layer），数据层（repository/dao），但是实际后果却是一个极其庞大的service层，这种写法可以算是一个面向过程开发的代码（procedural code）， 而不是面向对象开发。好处是简单，当业务不复杂时，确实没有必要使用一个庞大的面向对象开发框架（domain driven design）。
一个责任并不明确的service层主要有以下问题
1、业务逻辑分散在service层中，当我们需要确认或者检查某个业务逻辑时，可能要在多个service类中寻找，也许并不那么容易，另外如果同样的业务逻辑在多个service类中用到时，那么可能会存在大量的重复代码，这种重复代码对于维护人员来说就是恶魔。
2、在service层中，每个entity都有对应的service类时，service层会有过多的依赖，甚至是循环依赖关系，而不是由松散耦合的service类构成service层，理想中的service层应该是由具有单一责任的service类构成，并且这些service类具有松耦合关系，如果不是这样的service层，将难以理解，维护和重用。
主要的解决方法是
1、将与entity相关的业务逻辑统一放到领域模型对象相关的类中，即所谓的domain service中。这样做的好处时，传统概念中的service层仅仅处理应用相关的业务逻辑，即作为Application Service。然后domain service中处理domain 内的业务逻辑。业务逻辑将按照domain和application的方式分开，容易定位和维护。传统意义上的applicationservice层将变得整洁。
2、在domain service中我们将按照entity来编写对应的service，这些都是特定的service，很小，仅仅面对很专一的功能。举例来说，如果应用中的某个service提供person类的crud， 同时还提供用户帐号的操作，那么我们应该将person的crud单独放到一个service中，然后将用户帐号相关的操作放到另一个service中。
所有这些分层方式都是为了解决应用从小项目成长为大项目时可能遇到的隐患，代价是在项目还小时，增加了项目的复杂度，往往一句代码就能搞定的事情，却要拆到三个类中去。但是太多的实际例子表明，如果没有好的架构，当小项目膨胀到一定程度时，往往是无法维护的，只能全部推倒重写。
在Domain Driven Design中如何区分各种Service？
在DDD中，service有三种类型
Domain Service
Domain Service: 用于放置领域对象相关的业务逻辑，这些业务逻辑通常并不适合放到entity中，也不是常见到的CRUD(这些应该放到Repository)， 将Domain Service 和Domain Objects放到一起是合理的，它们都是关注于domain相关的业务逻辑。在Domain Service中可以使用注入repository的方式来使用entity对应的repository。
举一个例子：
一个图书馆有三个entity：Book， Client，Inventory， 当把一本书借给一个客户时，就对应了一个Domain Service。在一个例子，在Eric Evans的《Domain Driven Design》书中，转账服务（FundsTransferService）也是一种domain service，它涉及到帐号BankAccount，但是并不适合放到BankAccount中。
Application Service
Application Service: 用于为应用外的client或consumer提供应用级别的服务，比如一个外部客户端（程序）需要使用某个entity的CRUD时，这些服务程序放到Application Service。Application Service通常会使用Domain Service和repository来处理外部的请求。常见的场景是，从repository中拿到一些domain objects， 然后执行某些操作，在将其放回repository（或者不放）， Application Service对应着大部分用户使用场景，在写一个应用时，可以先从Application service写起，这样可以很好界定应用的功能和范围。repository虽然可以在某些场景下注入到domain service中，但是更常见的是注入到applicatinoservice中。
Infrastructure service
还有一种Infrastructure service：用于抽象一些技术问题，比如消息队列，邮件服务
具体例子spring-petclinic
======================================================
以下转载：：https://blog.csdn.net/ITzxr/article/details/100083203
Domain Driven Design 目录结构层级
├── Application.java
├── assembler DTO 组装器：将领域对象组装成 DTO
├── config 配置文件目录
├── constant 常量、枚举目录
├── domain 领域层
│ ├── event 领域事件：MQ event
│ ├── model 领域对象
│ ├── repository 领域仓库
│ ├── service 业务领域服务
│ └── translator 翻译器：将持久化层 Entity 或 DTO 翻译为领域对象。
├── infrastructure 基础设施目录
│ ├── exception 异常
│ ├── interceptor 权限拦截
│ ├── repository 领域层仓库具体实现
│ │ ├── dao mysql、oracle、mongodb
│ │ │ └── impl
│ │ ├── mock 哑实现
│ │ │ └── impl
│ │ └── redis redis 缓存
│ │ └── impl
│ ├── runner 程序启动初始化 runner
│ ├── task 定时任务
│ ├── transport 第三方服务交互
│ ├── util 工具类
│ └── validation 校验层
├── service 应用服务层
└── ui 对外开放的用户层，User Interface
├── controller 控制器
└── dto 用于外部数据交互的 DTO
├── request
└── response
框架说明
User Interface 用户层
用户层，对外以各种协议提供服务，包含：
DTO
包括 request 和 response 两部分，通过它定义入参和出参的契约，在 DTO 层可以使用基础设施层的 validation 组件完成入参格式校验
Controller
Controller 使用基础设施层公共组件完成通用的工作：
通过注解 RequestMapping 添加 servlet 路由
通过 interceptor 完成登录权限/角色校验
简单的数据转换
Application Layer 应用层
Service
应用服务层，组合 domain 层的领域对象和基础设施层的公共组件，根据业务需要包装出多变的服务，以适应多变的业务服务需求。
应用服务层主要访问 domain 领域对象，完成服务逻辑的包装。
应用服务层也会访问基础设施层的公共组件，如 redis，完成领域消息的生产和获取等。
Assembler
组装器，负责将多个 domain 领域对象组装为需要的 DTO 对象，比如查询帖子列表，需要从Post（帖子）领域对象中获取帖子的详情，还需要从 User（用户）领域对象中获取用户的基本信息。
组装器中不应当有业务逻辑在里面，主要负责格式转换、字段映射等职责。
Domain Layer 领域层
业务领域层，是我们最应当关心的一层，也是最多变的一层，需要保证这一层是高内聚的。确保所有的业务逻辑都留在这一层，而不会遗漏到其他层。按照 DDD（domain driven design）理论，主要有如下概念构成：
Domain Entity
领域实体对象。有唯一标识（主键），可变的业务实体对象，有自己的生命周期。比如门店就是一个业务实体，它需要有一个唯一性业务标识表征（门店 ID），同时它的状态（开店/停业）和内容（名称/地址）可以不断发生变化。
Domain Value Object
领域值对象。可以没有唯一性业务标识，且一旦定义，就不可变的，它通常是短暂的。这和Java中的值对象（基本类型和String类型）类似。比如门店领域中，门店的位置信息可以理解为是一个值对象，不需要为门店的位置信息定义唯一标识，直接使用门店 ID就可以找到每个门店的位置信息。同时，它具有省/市/区和详细地址几个属性，一旦任一个属性发生变化，则需要重建这个位置信息对象并赋值给门店实体的引用。
Domain Factory
领域对象工厂。用于复杂领域对象的创建/重建。重建是指通过 respostory 获取到对象后，重建或组装多个对象为领域对象。
Domain Service
领域服务。区别于应用服务，它属于业务领域层。
可以认为，如果某种方法无法归类给任何单一实体/值对象，则就为这些方法建立相应的领域服务即可。比如：门店收银服务，需要操作门店/会员两个实体。
传统意义上的 util static 方法中，只要涉及到业务逻辑的部分，都可以考虑归入domain service。
Domain Event
领域事件。领域中产生的一些消息事件，通过事件通知/订阅的方式异步操作，可以在性能和解耦层面得到好处。
Repository
领域仓库。我们将仓库的接口定义归类在 Domain 层，因为它和 Domain entity 联系紧密。User Interface 和基础实施的持久化层交互，都需要实现领域仓库接口对应的增删改查操作。
仓库的实际实现根据不同的存储介质而不同，可以是redis、mysql等。
鉴于存储介质可以同时存在有多套：redis、mysql，memory cache, 且各个存储介质的字段属性名不一致，因此需要使用translator来做翻译，将持久化层的对象翻译为统一的领域对象。
Translator
翻译器。将持久化层的对象翻译为统一的领域对象。
翻译器中不应当有业务逻辑在里面，主要负责格式转换、字段映射等职责。
Infrastructure Layer 基础设施层
基础设施层提供公共功能组件，供 controller、service、domain 层调用。
Repository impl
对 domain 层 repository 接口的实现，对应每种存储介质有其特定实现，如 mysql、oracle的 dao 等等。repository impl 会调用 mybatis、jooq、redis client完成实际的存储层操作。
Interceptor
权限校验器，判定客户端是否有访问该资源的权限。提供给User Interface层的Controller调用。
Exception
异常分类及定义，同时提供公共的异常处理逻辑，具体由ExceptionHandler实现。
Transport 第三方服务交互层
transport 完成和第三方服务的交互，可以有多种协议形式的实现，如http+json、二进制文件流，用于对第三方服务的请求和响应进行适配，提供一个防腐层的作用。
注意要点
各个 package 的详细解释参考上节框架说明，着重注意如下几点：
domain.repository 包里面只有仓库的接口定义，实际的实现交给了 infrastructure 中的 repository module，该做法被称作依赖倒置，好处在于确保 domain 层语义完整，同时对确保业务领域的一致性也有帮助，再者可以在 domain 实现内存形式的 repository 哑实现，从而让 domain 可以真正脱离掉 infrastructure
infrastructure.repository 作为仓库层，会将实体的增删改查操作委托给具体的存储层服务，如 mysql 对应的 dao 实现，还有 redis 的实现
少写应用层 Service，多把业务逻辑封装到 Domain
Controller 要瘦，仅处理消息或数据转发，Model 仅处理领域逻辑。而 Service 通常负责领域间的交互及某些预处理（比如数据验证、权限验证等等）
=============================================
NoSQL数据库
NoSQL数据库是持久化数据的另一种方式，但是与关系数据库的表格关系不同。这些新兴的NoSQL数据库已经有一个分类系统。您可以根据其数据模型找到它。
• Column (Cassandra, HBase, etc.)
• Document (CouchDB, MongoDB, etc.)
• Key-Value (Redis, Riak, etc.)
• Graph (Neo4J, Virtuoso, etc.)
• Multimodel (OrientDB, ArangoDB, etc.)
如您所见，您有很多选择。我认为最重要的功能是找到一个可扩展的数据库，并可以轻松处理数百万条记录。
Spring Data MongoDB
Spring Data MongoDB项目为您提供了与MongoDB文档数据库的必要交互。重要功能之一是您仍然可以使用使用@Document批注的域模型类并声明使用以下内容的接口CrudRepository <T，ID>。这将创建MongoDB用于持久性的必要集合。
以下是该项目的一些功能。
•Spring Data MongoDB提供了MongoTemplate帮助器类（非常
与JdbcTemplate相似）处理所有样板交互与MongoDB文档数据库一起使用。
•持久性和映射生命周期事件。
•MongoTemplate帮助器类。它还使用MongoReader / MongoWriter抽象提供低级映射。
•基于Java的查询，条件和更新DSL。
•地理空间和MapReduce集成以及GridFS支持。
•对JPA实体的跨存储持久性支持。这表示您可以使用标有@Entity和其他标记的类批注，并使用它们来保留/检索数据MongoDB文档数据库。
带有Spring Boot的Spring Data MongoDB
要将MongoDB与Spring Boot结合使用，您需要添加spring-boot-starter-datamongodb依赖项并有权访问MongoDB服务器实例。
Spring Boot使用自动配置功能来设置一切以便与MongoDB服务器实例进行通信。默认情况下，Spring Boot尝试连接到本地主机并使用端口27017（MongoDB标准端口）。如果您有MongoDB远程服务器，则可以通过覆盖默认值连接到该服务器。您需要使用application.properties文件中的spring.mongodb。*属性（简便方法），或者可以使用XML或JavaConfig类中的bean声明。
Spring Boot还会自动配置MongoTemplate类（该类与JdbcTemplate非常相似），因此可以与MongoDB服务器进行任何交互。另一个很棒的功能是您可以使用存储库，这意味着您可以重用用于JPA的相同接口。
嵌入式MongoDB
还有另一种使用MongoDB的方法，至少作为开发环境。您可以使用MongoDB Embedded。通常，您可以在测试环境中使用它，但是可以在带有运行时范围的开发模式下轻松运行它。
要使用嵌入式MongoDB，您需要添加以下依赖项。如果使用的是Maven，则可以将其添加到pom.xml文件中。
Maven pom.xml
<dependency><groupId>de.flapdoodle.embed</groupId><artifactId>de.flapdoodle.embed.mongo</artifactId><scope>runtime</scope></dependency>
然后在源码中书写如下annotation：
清单5-8显示了MongoClient bean的配置。当应用程序启动时，MongoDB Embedded将使用随机端口，这就是为什么还必须使用Environment Bean的原因。如果您采用这种方法来使用MongoDB服务器，则无需设置任何其他属性。
清单5-8显示了MongoClient bean的配置。当应用程序启动时，MongoDB Embedded将使用随机端口，这就是为什么还必须使用Environment Bean的原因。
如果您采用这种方法来使用MongoDB服务器，则无需设置任何其他属性。
清单5-9显示了修改后的ToDo类。该类使用@Document批注将其标记为持久性；它还使用@Id声明唯一键。
如果您有远程MongoDB服务器，则可以覆盖指向本地主机的默认值。您可以转到application.properties文件并添加以下属性。
[root@repo resources]# pwd
/david/pro-spring-boot-2-master/pro-spring-boot-2nd/ch05/todo-mongo/src/main/resources
[root@repo resources]# cat application.properties
## MongoDB
spring.data.mongodb.host=localhost
spring.data.mongodb.port=41906
spring.data.mongodb.username=springboot
spring.data.mongodb.password=pivotal
查看应用启动日志：
[root@repo ~]# mongo 127.0.0.1:41856MongoDB shell version: 2.6.12connecting to: 127.0.0.1:41856/testServer has startup warnings:2021-03-22T10:49:04.512+0000 I CONTROL [initandlisten] ** WARNING: You are running this process as the root user, which is not recommended.2021-03-22T10:49:04.512+0000 I CONTROL [initandlisten]2021-03-22T10:49:04.512+0000 I CONTROL [initandlisten]2021-03-22T10:49:04.512+0000 I CONTROL [initandlisten] ** WARNING: /sys/kernel/mm/transparent_hugepage/enabled is 'always'.2021-03-22T10:49:04.512+0000 I CONTROL [initandlisten] ** We suggest setting it to 'never'2021-03-22T10:49:04.512+0000 I CONTROL [initandlisten]2021-03-22T10:49:04.512+0000 I CONTROL [initandlisten] ** WARNING: /sys/kernel/mm/transparent_hugepage/defrag is 'always'.2021-03-22T10:49:04.512+0000 I CONTROL [initandlisten] ** We suggest setting it to 'never'2021-03-22T10:49:04.512+0000 I CONTROL [initandlisten]
> db.textIndexTest.find({$text:{$search:"王"}})
{ "_id" : ObjectId("6058791f29f9c258cf4d6921"), "author" : "张 王", "title" : "你好", "article" : "测试数据" }