问题描述
最近我正在学习DDD。我也对六角结构（也称为ports and adapters）有一些经验。我想将自己的见识付诸实践并创建一个交易应用程序。起初，我不希望拥有具有某些基本功能的monolithic应用程序。我在结合DDD和微服务以及端口和适配器以及MVC方面有经验，但是我目前面临的挑战对我来说是新的。
因此，这是应用程序应具备的一些功能：
当然，还有其他一些东西，例如身份验证。还存在数据库和Web ui等服务。
所以我的第一个问题是bounded context是什么？ sub domains是什么？例如，用户希望查看实时价格数据，而在后台，应用程序将以持久方式保存此数据，而不管用户是否在查看价格！现在，由于两个功能共享很多，它们是在同一bounded context中还是在同一subdomain中？
我的下一个问题是打包应用程序。在阅读了许多文章之后，仍然无法将DDD与Onion的{{1}}风格结合起来。我正在使用hexagonal，但我认为总体结构应该是相同的跨语言。我想出了一个这样的结构：
golang很明显，这里缺少很多东西，我不知道将src
├─── cmd
│ └─── Main files
│ └─── DI files
├─── sub-domain1
├─── sub-domain2
│ ├─── domain model
│ └─── value objects
│ └─── entity objects
│ ├─── application service
│ └─── infrastructure
│ └─── ports
│ └─── adapters
...
，repositories，DTO's和许多其他对象放在哪里。我也不确定这种结构，因为我看到一些实现将目录嵌套在一起，就像洋葱一样！目前，我不想拥有多个模块和二进制文件，但应用程序可能会增长到多个微服务，如果发生这种情况，我将不愿处理Event bus（可能是它永远不会发生，但是就像现实生活中的那样，我想它可能会发生。
我很困惑，有些指导可以帮助我很多。谢谢
解决方法
首先，如果您从单体应用开始，您可以将所有功能放在一个模块中，但将它们分开在不同的包中（subdomain1、subdomain2）。从一个模块开始将使您更加简单。然后，如果您的应用不断发展，并且有更多人在为多个利益相关者工作，您就可以创建微服务。
什么是有界上下文？什么是子域？
有界上下文是 DDD 的核心模式。请参阅这篇文章：https://martinfowler.com/bliki/BoundedContext.html
您的有界上下文取决于您的组织：
- 有多少个小组、团队在开发应用程序？
- 他们使用相同的语言吗？
如果有多个团队并且这些团队使用不同的语言来谈论组织（您的应用程序管理的），那么您可以创建多个子域。
每个子域都是独立的。例如，您可以在第一个子域（监控和保存价格/交易量）中使用一个价格实体，在第二个子域（根据策略执行自动交易）中使用不同字段的另一个价格实体。 每个实体的字段和方法（特征）将对应每个子域的语言。
既然两个功能共享很多，那么它们是在同一个有界上下文中还是在同一个子域中？
就像我之前所说的，每个子域都可以包含一个 Sale 实体。在上面的文章中，每个子域都包含 Customer 实体。但这些实体可能不同（字段和方法）。
我的下一个问题是打包应用程序。
最重要的是，您的域保持干净，并有明确划分的子域。而且这个领域必须是独立的，不能依赖技术。
之后，您就可以将所有技术内容都放在基础设施中。