1

最近我在学习 DDD。我也有一些六边形架构（也称为ports and adapters）的经验。我想将我的想法付诸实践并创建一个交易应用程序。起初我不想拥有一个monolithic具有一些基本功能的应用程序。我有组合DDD和微服务以及端口和适配器以及 MVC 的经验，但我目前面临的挑战对我来说是新的。

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

  • 监控和保存价格/数量
  • 按照策略执行自动交易
  • 回测策略
  • 为交易者创建交易历史和交易日志

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

所以我的第一个问题是什么bounded context？是什么sub domains？例如，用户想要查看实时价格数据，并且在后台，应用程序会以持久的方式保存这些数据，而不管用户是否正在检查价格！现在由于两个功能共享很多，它们是相同bounded context的还是相同的subdomain？

我遇到的下一个问题是打包应用程序。看了很多文章还是想不通我怎么能DDD和Onion风格结合起来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许多其他对象。此外，我不确定这种结构，因为我已经看到一些实现将目录相互嵌套，就像洋葱一样！现在我不想拥有多个模块和二进制文件，但是应用程序有可能增长到多个微服务，如果发生这种情况我不想处理heavy refactoring（可能永远不会发生，只是作为现实世界的实践，我想它可能会发生）。

我很困惑，我的一些指导可以帮助我很多。谢谢

4

1 回答 1

1

首先，如果你从一个单体应用程序开始，你可以把所有的特性放在一个模块中，但将它们分开在不同的包中（子域1，子域2）。从一个模块开始将使您更加简单。然后，如果您的应用程序不断发展，并且有更多人在使用它，那么对于多个利益相关者，您可以创建微服务。

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

限界上下文是 DDD 的核心模式。见这篇文章：https ://martinfowler.com/bliki/BoundedContext.html

您的有界上下文取决于您的组织：

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

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

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

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

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

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

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

之后，您可以将所有技术内容放入基础架构中。

于 2021-01-18T23:35:25.013 回答