首先引经据典 , 参考官方架构草图，DDD总体结构分为四层 : Infrastructure(基础实施层)，Domain(领域层)，Application(应用层)，Interfaces(表示层，也叫用户界面层或是接口层)，各个层面的作用下面介绍。
对于DDD的设计而言，最重要的是如何去划分领域，划分好边界。在代码设计上，之前有看到过大佬用模块(Modules)来进行上下文界定和划分。如图下 :
而对于微服务而言，就非常适合从业务上去划分以上的各个Modules，划分好各个业务板块。
微服务 + DDD，个人觉得应该是首先是从微服务的角度(如何划分微服务)考虑去划分大的业务模块，每一个微服务都应该是一个可以单独部署，各司其职的模块；
而在微服务实际开发中，结合DDD的思想去划分所有属于自己的领域。
如图示例，对于我这个Project而言，是模块已经划分好的微服务应用，代码设计上就分为 Infrastructure，Domain，Application，Interfaces :
Infrastructure 层 : 基础实施层，向其他层提供通用的技术能力(比如工具类,第三方库类支持,常用基本配置,数据访问底层实现)
Domain层 : 主要负责表达业务概念,业务状态信息和业务规则；是整个系统的核心层,几乎全部的业务逻辑会在该层实现。
Application层 : 相对于领域层,应用层是很薄的一层,应用层定义了软件要完成的任务,要尽量简单。
注 : 这里图里面所说的对内对外，对程序而言，事实上是从展现层调用应用层，应用层调用领域层，领域层或调用基础设施层。
Interfaces层 : 负责向用户显示信息和解释用户命令，请求应用层以获取用户所需要展现的数据(比如获取首页的商品数据)
以上，就是个人 对 微服务+DDD的代码结构示例，完整代码详见 https://github.com/EalenXie/springcloud-microservice-ddd
无论我们代码结构如何规划，也并非一成不变，应该从实际出发，去思考划分结构的意义。此例子是对于微服务+DDD反应到实际开发，代码的结构设计上的一种初步的思考与探索,一个样板工程，不应该成为我们对实际DDD思考与设计的限制，本例仅供参考。
(我个人对微服务的理解)Tips :
微服务架构设计，一个微服务应该就是一个可单独部署，可运行的应用，也就是微服务最小的运行单元。
微服务本身内部高度内聚，微服务与微服务之间低耦合。
首先对于应用划分上，就应该想清楚每个微服务的职责，每个微服务服务内部建立起自己的依赖，完成自己的职责和业务。
微服务与微服务之间交互通过HTTP或RPC接口调用，降低微服务之间代码实现和业务的耦合。
微服务的实现不应该受限某程序语言(或Java，或Go，或Python)，不应该受限于某框架(或SpringCloud，或Dubbo，或各种RPC框架等等)。
我的代码结构是对于一个微服务本身(即应用)划分的，领域是对于微服务内部本身而言的，即这个微服务涉及哪些领域。
首先从大的方向去划分每一个微服务，然后再从每一个微服务确定所包含的领域，领域的边界，等等。
比如划分了一个 认证授权服务，那么 领域可能有 用户，权限；实体可能有角色，资源等等。领域行为有授权登录，用户退出，授权等等。
不要被框架和结构本身所限制！
