Iphone SE 以上版本的二手，强烈推荐。前提一、没撞到坏运气。前提二、楼主能适应 IOS 的封闭环境。

好吧，整体架构上发现也不对，Web 与 Worker 的职责和关系是：Web 负责生产和存储事件； Worker 负责消费事件。而不是我原来想要的：Web 独立负责业务，生产事件时仅存储事件，主业务与存储事件有强一致性（即在同一个事务中）； Worker 负责异步的将事件发送到消息中间件。

日常使用，10M 足够了，除非你想干特别的事情，你要知道便宜的云服务器 1M 带宽也够用。

以前（被总理要求提速前），电信上传严格限制到不超过 1M （ ADSL 甚至只有 0.5M ），联通上传限制 2M 但不是特别严格的限制。那时候电信的 P2P 下载只能当吸血驴。

一般来说，P2P 要求的上传下载比是 1/8，所以 10M/100M，20M/200M 是不影响 P2P 的合理使用的。

请记得一定只要在本地制造文件，不要有任何主动上传的念头，只能等对方扫描后自己上传。
对方太容易通过白名单特征过滤掉你做的文件，所以这样做基本没用。但是，这能避免你吃官司。
如果你主动上传，将涉嫌入侵计算机这样的犯罪行为，最低也是防卫过当。

这种情况，如果你不能搜集证据正面对方入侵了你，你就只能忍着。

@xian 你在把内容设置为公网可见，并且没有用 robots.txt 禁止的时候，就已经默认授权了搜索引擎（包括其他网站）可以爬你的内容。如果你只想让搜索引擎爬，不让其他网站爬，那么只能靠技术手段阻止，不能靠法律手段。（然而对方有可能起诉你的技术手段不正常竞争，参见 LinkIn 的一个官司，用技术手段阻止某个公司搜集分析数据，官司输了）

如果你把内容放到了公网上，那么你的内容就是能被任何“人”查看的，这个“人”，即包括对你有用的人，也包括对你没用的人，更包括搜索引擎和机器人。放到公网上，又只想让特定的人看，这是不受法律支持的。

理论依据：HTTP 单次访问是无状态的，但 HTTP 连续访问是有会话状态的；会话状态由服务器保存；只要能够保证获取验证码、使用验证码这两个请求处于同一个会话，那么验证码就是可以验证的。

HTTP 会话状态是 OSI 第七层应用层独立管理的事，跟第四层传输层 TCP 连接没有任何关系。

HTTP 会话跟踪原理：首次连接服务器生成唯一标识，并且通知客户端；后续连接，客户端都带上该标识；服务器根据唯一标识，判断是否属于同一个会话。唯一标识由服务器生成和校验，客户端只能够暂存和传递，所以该会话是完全由服务器控制的。

HTTP 会话 Cookie 实现方式：服务器通过 set-cookie 将唯一标识通知给客户端，一般都会制定 cookie 的有效期是内存级别，级浏览器关了 cookie 就没了。

HTTP 会话 URL 重写实现方式：服务器通过 URL 重定向将唯一标识通知给客户端，唯一标识就在新的 URL 地址上，客户端不保存唯一标识，但后续的所有请求的 URL 地址中，都回带上唯一标识。此方式很容易失效。

以上两种，只是传统的实现方式，并不是唯一的。你完全可以抛开浏览器和服务器框架，自己实现会话跟踪。例如：如果服务器愿意，浏览器可以通过 H5 的 web 存储暂存唯一标识；服务器也可以抛开语言框架，自己写业务代码，用 redis 或者独立服务管理唯一标识（此时集群就不是事了）。甚至，经服务器允许后，多个客户端通过共享唯一标识，也可以共享会话；当然会话管理服务器、验证码服务器、业务服务器也可以是不同的服务器。

个人开发的语言，要替代不同公司、不同行业的众多软件工作者几十年间不断完善的语言 /平台 /框架 /类库 /生态，不是不可能，但是难。

@xian
搜索引擎爬的数据，是网站让爬的。请参见 robots.txt 。
robots.txt 定义了不让爬，搜索引擎还爬的话，也不是窃取，是抢劫。

当初急用，虽然知道 V2EX 有优惠，但是还是买了京东二手，特意挑了个贵的 1200。
当电子钱包和京东签到器，已经用了 4 个月了。

请用 uwp 版本客户端。

补一下 DDD 的软件架构。
简单分层架构：由下到上依次是：模型层（含 Entity/Aggregation、Value Object、Repository ）、Domain Service 层、Application Service 层。Domain Service 层是可选的，并且它仅仅是在调用关系上处于上层，业务关系上它跟模型层是平级的。

依赖倒置架构：由下到上依次是：领域核心层（ Entity/Aggregation、Value Object、Domain Service、Repository 接口部分）、Application Service 层、基础设施层（ JPA、Hibernate、数据库、Domain Service 技术实现部分……）。此时的分层只表示业务依赖关系，与调用关系无关了。

还有更复杂的架构。所有架构中都没有“ Dao ”，数据库也从来不会参与建模。

@abcbuzhiming 你的这个需求，“场景 1 按照方式一搜索、场景 2 按照方式二搜索”是业务逻辑，不是 Dao/Repository 该干的事。

在传统模式中，Dao 层提供 findByUserName(String userName) findByNickName(String nickName)两个方法，Service 层决定调用哪个方法。

在 DDD 模式中，Repository 提供两个检索方法，领域服务或者应用服务决定调用哪个方法。

@abcbuzhiming “不应该考虑表、字段等任何数据库方便的概念”，是领域驱动设计的要求。领域驱动设计中，要求完全按照面向对象的方式去建模，数据库的部分由 Jpa 自动去处理。形象一点的说是：引入了 JPA 的实现（ Hibernate 等）后，开发人员只需要设计 Java 类，数据库部分（包括结构和读写 SQL ）由 JPA 自动处理。

@abcbuzhiming Repository 不是 Dao，贫血领域模型用 Dao，常规领域模型用 Repository，它俩永远不会一起使用。

领域驱动设计中的“存储库”的含义是：对象集合以及该集合的读写行为，形象一店的说，就是对象的仓库和仓库管理员。Spring 核心给的 Repository 的定义是：表示“存储库”,若是传统 Java EE 模式（这是好听的说法，说不好停的就是老旧的贫血模型模式），也可以表示 Dao。

下面是 spring core 中 @Repository 的 javadoc 和谷歌翻译
https://docs.spring.io/spring/docs/5.0.8.RELEASE/javadoc-api/org/springframework/stereotype/Repository.html

表示带注释的类是“存储库”，最初由域驱动设计（ Evans，2003 ）定义为“用于封装模拟对象集合的存储，检索和搜索行为的机制”。
实现传统 Java EE 模式（如“数据访问对象”）的团队也可以将此构造型应用于 DAO 类，但在此之前应注意理解数据访问对象和 DDD 样式存储库之间的区别。这个注释是一个通用的刻板印象，个别团队可能会缩小其语义并在适当时使用。
如此注释的类 DataAccessException 在与 a 一起使用时有资格进行 Spring 翻译 PersistenceExceptionTranslationPostProcessor。带注释的类还阐明了它在整个应用程序体系结构中的作用，以用于工具，方面等。
从 Spring 2.5 开始，这个注释也可以作为一个特化 @Component，允许通过类路径扫描自动检测实现类。

首先纠正楼主两点：
一、Hibernate、Jpa 和基于二者的 Spring Data Jpa，都没有“ Dao ”这个概念。
二、既然用了 Spring Data Jpa，那么除非是是否旧的数据库，不应该考虑表、字段等任何数据库方便的概念。

其次，楼主第二段的需求，我没看看明白。

Spring Data Jpa 只是 Hibernate 的一个上层封装，通过约定加自动生成的方式，简化 Jpa/Hibernate 的编码。它本身并不是 ORM，也没有对使用方式做任何强制限制（你可以自由的添加自定义实现）。

@zjl03505 按照你对“案”的理解，你是真适合到驻京办去工作。
接你下一条回复，急救转给 120，火警转给 119，这是 110 的义务，若是因为没有转接而造成损失，是要吃行政诉讼的。

@Decouple 代码即注释有个前提，所有使用代码的人对代码的理解方式相同。这要求开发期必须有通畅的沟通，维护期必须有良好的交接。此时敏捷开发、领域模型通用语言就成了必要条件，一般团队是达不到这俩必要条件的。