听闻了 DDD(领域驱动)的牛，想实践一下。
已看完《领域驱动设计精粹》、看了 50%《实现领域驱动设计》，手头上还有《领域驱动设计》
想找个从搭建项目、分包、建领域模型的视频项目教程学一下真实的编码（不是讲 PPT 概念的），最好是 java
已在 B 站、google 、网易课堂、慕课、腾讯课堂等搜索后无果，这一块国内是不是还属于”蓝海”，教人做项目的视频已经一大堆了
在 github 上找到了一个可能符合预期的，张逸大佬的收费 199，有点小贵。 https://github.com/agiledon/eas-ddd
实话说，国内的能用 DDD 来做项目的，真的少，可以在 V 站问一下，大部分都是会认为不适合，脱离不了数据库思维，做毛线 DDD 。
其实这个例子，已经被重写成各种版本（不同的语言，框架），Github 上大把。
Eclipse EE4J 官方 Jakarta EE(Java EE 继承者) 也维护了一个 JakartaEE 版本的 CargoTracker 。一个程序熟悉所有的 Java EE 规范（之后再写 Spring 也是不费用吹灰之力），熟悉 DDD 设计理念（完全抛弃数据为中心的设计）。
相比成熟规范和开源框架 Spring，Hibernate 等，这个完全是应用级别，难度系数极低。
https://github.com/eclipse-ee4j/cargotracker
我的 Fork：
https://github.com/hantsy/cargotracker
thoughtworks 的一个 Java DDD 范例项目：
https://github.com/e-commerce-sample/ecommerce-order-service
微软官方的 ddd 教程项目（.Net ）：
https://docs.microsoft.com/en-us/dotnet/architecture/microservices/microservice-ddd-cqrs-patterns/
https://github.com/dotnet-architecture/eShopOnContainers
https://github.com/dotnet-architecture/eShopOnWeb
（虽然是.Net ，但是 AspNet 和 SpringBoot 差别不大）
回复上那些说 DDD 不实际、DDD 只适合大公司的复杂业务等说法：
CRUD Boy 无法理解 DDD 属正常现象，但是如果轻视 DDD，那就注定只能当一个低级的 CRUD Boy 。
例如六边形架构 其实就是接口隔离原则，它提倡高层次的业务逻辑不要跟低层次技术细节代码耦合，
两者都要依赖接口，例如发送消息到消息队列，从业务层面上来看应该抽象出一个接口，
至于具体怎么发不应该依赖具体的实现例如 kafka 跟 rabbitMQ，这样以后你更换消息中间件不需要改写业务代码，
但是实际上在 CRUD boy 的眼中，耦合什么的都不是问题.. 反正就是 Controller 捅到 Service 跟 DAO 一把梭
例如共享内核跟界限上下文 其实本质上的核心思想就是单一职责原则跟适配器模式，如果你在大型系统中建模，
总想用一个模型概念去解决所有的领域问题，那么你的模型概念就难以理解，
以我上家为例，我们实践 DDD 做了一套护士教育考试系统，但是有的医院硬是要塞进去一个护士排班系统，
这样在建模的时候 就要应用共享内核，
在考试系统上下文我们关心的是护士的职业级别，因为根据一些公立医院的规则
护士通过考试，应该在批准后得到晋升，这样在这个上下文我们关注的是护士的 职业等级相关的属性
在排班系统上下文，我们关注的是护士的工作时长，护士的请假，医院的排班规则等
如果你想建一个大一统的护士模型，那么对不起，这个护士模型没有任何人能理解透，这还是两个系统，
如果再涉及到医院护士 护士长等审批流程系统之类的，那么这个模型的职责会大到你难以理解。
所以共享内核跟界限上下文的根本思想就是 单一职责原则，做开发如果有多年经验的，一般都会把注意力放在建模跟概念最小完整性，这样的系统会更容易维护，至于填空写 CRUD 的人，招几个 2-3 年的年轻人就行了。
1. 非本质性困难
例如 CAP 高并发系统设计 这些都是非本质困难，随着技术进步这些困难早晚都会被解决掉，例如
阿里的 seata 就在解决分布式系统中的分布式事务问题 提供 TCC SAGA 等方案，而这些方案随着技术成熟，未来会越来越对业务层透明，
另外随着一些中间件的成熟，实现可靠消息队列也将不再成为难题，业务层面上不用再需要考虑幂等 消息丢失 异常处理之类的，只要考虑业务上如何设计妥协，因为异步消息系统存在上下文丢失的问题。
在汇编时代，程序员需要自己手动管理栈，在 C 语言时代，程序员需要自己手动管理堆内存，在 C++时代，程序员需要关注 RAII 跟循环引用以及智能指针的引用计数回收模型，在 Java 时代，程序员总算从内存管理中解放出来了，只需要关注业务逻辑了
2. 本质性困难
大型系统的概念完整性以及单个系统模块复杂度失控的问题，如果你的系统只是几十个 CRUD 接口，那么你大可不必 费尽周折来设计系统，因为这样的系统，大概 1-2 年后就会被重写，即使重写损失也不大，所以像 DDD 这种设计哲学跟理念，它只能被用在大型系统中，例如像阿里这样的公司，你很难在上百个业务开发团队 建立一个共通的概念模型，例如一个淘宝用户，在各个业务团队中，它所呈现的概念是完全不一样的，只有这样的大系统才有应用 DDD 的价值跟需求