Architecture 领域驱动设计与六边形体系结构

最近我在学习DDD。我对六边形体系结构（也称为

端口和适配器

）也有一些经验。我想把我的想法付诸实践，创建一个交易应用程序。首先，我不希望有一个具有一些基本功能的

单片

应用程序。我有将

DDD

与微服务、端口、适配器和MVC相结合的经验，但我目前面临的挑战对我来说是新的

因此，以下是该应用程序的一些预期功能：

• 监控和节省价格/数量
• 按照以下策略执行自动交易
• 回测策略
• 为交易员创建交易历史记录和交易日志

当然还有其他一些事情，比如身份验证。此外，数据库和web ui等服务也确实存在

所以我的第一个问题是什么是

有界上下文

？什么是

子域

？例如，用户希望看到实时价格数据，而在后台，无论用户是否检查价格，应用程序都以持久的方式保存这些数据！既然两个功能共享很多，它们是在同一个

有界上下文中还是在同一个
子域中

我遇到的下一个问题是打包应用程序。在阅读了许多文章后，我仍然不知道如何将
DDD
与
Onion
风格的
hexagon
结合起来。我使用的是
golang
，但我认为整体结构应该是相同的跨语言结构。我提出了这样一种结构：

src
├─── cmd
│    └─── Main files
│    └─── DI files
├─── sub-domain1
├─── sub-domain2
│    ├─── domain model
│         └─── value objects
│         └─── entity objects        
│    ├─── application service
│    └─── infrastructure 
│         └─── ports
│         └─── adapters 
...

很明显，这里缺少很多东西，我不知道应该把
存储库
，
DTO的
，
事件总线
和许多其他对象放在哪里。此外，我也不确定这种结构，因为我看到一些实现将目录嵌套在彼此内部，就像洋葱一样！目前，我不希望有多个模块和二进制文件，但有可能应用程序会扩展到多个微服务，如果发生这种情况，我不想处理
重重构
（可能永远不会发生，但就像现实世界中的实践一样，我想它可能会发生）

我很困惑，一些指导可以帮我很多。谢谢
首先，如果您从一个单片应用程序开始，您可以将所有功能放在一个模块中，但将它们分开放在不同的包中（子域1、子域2）。从一个模块开始将使您更加简单。然后，如果您的应用程序不断发展，并且有更多的人参与其中，那么对于多个涉众，您可以创建微服务

什么是有界上下文？子域是什么

有界上下文是DDD中的中心模式。见本文：

您的受限上下文取决于您的组织：


有多少组、团队在应用程序上工作
他们使用相同的语言吗

如果有多个团队，并且这些团队使用不同的语言谈论组织（应用程序管理的组织），那么您可以创建多个子域

每个子域都是独立的。例如，您可以在第一个子域（监控和保存价格/数量）中有一个价格实体，在第二个子域（执行自动交易跟踪策略）中有另一个具有不同字段的价格实体。
每个实体的字段和方法（特征）将对应于每个子域的语言

既然两个功能共享很多，它们是在同一个有界上下文中还是在同一个子域中

如前所述，每个子域可以包含一个销售实体。在上面的文章中，每个子域都包含客户实体。但这些实体可能不同（字段和方法）

我遇到的下一个问题是打包应用程序

最重要的是，您的域保持干净，具有划分良好的子域。这个领域必须是独立的，不依赖于技术

在那之后，你可以把所有的技术资料放在基础设施中。
1 IMO中的问题太多了。如果需要的话，尽量集中精力，问很多问题。这个问题听起来像。。。如何设计DDD交易系统。