Logistics Service For Channel（LCS)
git clone --recurse-submodules https://github.com/heshaofeng1991/ddd-sample.git
go install github.com/deepmap/oapi-codegen/cmd/oapi-codegen
服务代码生成依赖yaml文件
存放 main.go
应用层，组织业务场景，编排业务，隔离场景对领域层的差异
应用层遵循面向对象核心思想中的 “关注点分离” 理念。应用层的关注点在于业务场景的处理。例如，对于一个服务多种类型用户的应用，to C 的网页界面和后台管理界面对应的是不同的业务场景。对于新用户注册这个业务来说，通过 to C 的网页注册和通过后台管理界面进行后台注册是不同的业务场景。然而，“用户注册”在系统层面的基本逻辑是一样的。所以，“用户注册”的基本业务逻辑可以交由领域层来实现。而两种不同渠道进行用户注册所需要进行的身份验证等逻辑，可以设计在应用层进行实现。这样便能达到关注点分离，复用核心业务逻辑的目的。
2.1.1. 关心处理完一个完整的业务
2.1.2. 该层只负责业务编排，对象转换，而具体的业务逻辑由领域层实现
2.1.3. 虽不关心请求从何处来，但关心谁来、做什么、有没有权限做
2.1.4. 利用不同的领域服务来解决问题
2.1.5. 对最终一致性有要求的业务和事务处理需要放到应用层来处理
2.1.6. 功能权限放到这层
通俗来说，领域就是业务知识。业务有一些内在规则，存在专业性; 比如财务、CRM、OA、电商等不同领域的业务规则不同。计算机只是业务规则的自动化。
3.2.1. 不关心场景，关心模型完整性和业务规则
3.2.2. 不关心谁来，不关心场景完整的业务，关心当前上下文的业务完整
3.2.3. 强一致性事务放到这层，聚合的事务是 “理所当然的”
3.2.4. 对应到分布式系统中的 domain service、后台等概念
3.2.5. 领域层做业务规则验证
3.2.6. 数据权限放到这层（比如只允许删除自己创建的商品），因为数据权限涉及业务规则
3.2.7. 根据业务情况，参考反范式理论，跨上下文使用值对象做必要的数据冗余
4.1.1. 提供具体的技术实现，比如存储，基础设施对业务保持透明。
4.1.2. 基础设施层并不是指 MySQL、Redis 等外部组件，而是外部组件的适配器，Hibernate、Mybatis、Redis Template 等，因此在 DDD 中适配器模式被多次提到，基础设施层往往不能单独存在，还是要依附于领域层。技术设施层的适配器还包括了外部系统的适配，互联网产品系统的外部系统非常多，常见的有活体监测、风控系统、税务发票等。
4.2.1.关心存储、通知、第三方系统等外部设施（防腐层隔离）
4.2.2.基础设施的权限由配置到应用的凭证控制，例如数据库、对象存储的凭证，技术设施层不涉及用户的权限
接入层负责的是系统的输入和输出。
接入层只关心沟通协议，不关心业务相关的数据校验。 接入层的实现是与业务应用强相关的，不同的业务应用有不同的实现方式。例如，对于普通的 Web 应用，基于 HTTP 协议的 API 是一种接入层实现方式；对于IoT传感器的数据上传业务，接入层的实现可能需要基于 websocket 或 MQTT 协议。
5.1.1.接入层对应用数据透明，只关心数据格式而不关心数据的内容
5.1.2.在大部分单体系统中接入层通常被框架实现。例如，在 Spring Boot 框架中，HTTP 协议的 API 设计不需要关注 HTTP 协议本身。
5.1.3.在分布式系统中接入层通常被网关实现。
仅仅只是服务的一个过渡层，比如我们某些服务使用的是CQRS架构理念
通用语言（Ubiquitous language）是指在软件设计中，业务人员和开发人员需要使用无歧义的统一语言来对话。
这些语言包括对概念的统一理解和定义，以及业务人员参与到软件建模中，否则业务的变化会造成软件巨大的变化。
存放服务脚本