我正在尝试研究如何在嵌入式软件系统的上下文中使用六边形(端口和适配器)架构。
如果我理解正确,架构是这样的。
/-----------------\ /-----------------------------\
| | | |
| Application | | Domain |
| | | |
| +----------+ | | +---------+ |
| | +-------------->|interface| | /-------------------\
| +----------+ | | +---------+ | | |
| | | ^ | | Infrastructure |
| | | | | | |
\---------------+-/ | +---+---+ +---------+ | | +----------+ |
| | +---->|interface|<-------------+ | |
Code that allows | +-------+ +---------+ | | +----------+ |
interaction with | | | |
user \--------------------------+--/ \-----------------+-/
Business logic What we (the business)
depend on - persistence,
crypto services etc
让我们举一个具体的例子,其中一个用户界面是触摸屏,主控制器通过串行 UART 与之对话。该软件发送控制命令以在屏幕上绘制元素,并且用户操作会生成文本消息。
我看到在这种情况下工作的位是:
串行驱动程序
- 通过 UART 发送数据
- 接收数据(调用 ISR)
屏幕命令生成器
- 屏幕响应/事件解析器
- 业务逻辑,例如呈现和响应菜单、小部件等
我正在努力解决的问题是这些作品应该放在哪里。直觉上,我觉得是这样的:
- 基础设施- UART 驱动程序
- 领域- 业务逻辑
- 应用程序- 消息生成器/解析器
但是这种安排迫使应用程序和基础设施之间存在依赖关系,其中解析器需要检索数据,而构建器需要通过 UART 发送数据。
将消息构建器和解析器带入基础设施或域将整个用户交互从应用程序中移开。
无论我怎么看,它似乎都违反了我上面绘制的图表的某些方面。有什么建议么?