Question

我正在尝试在小型REST服务中实现DDD /干净架构原则。我有一个任务班：

@attr.s
class Task:
    id: str = attr.ib()
    url: str = attr.ib()

    images_paths: Optional[List[str]] = attr.ib(default=None)
    text_path: Optional[str] = attr.ib(default=None)

我需要两种json序列化方法。我需要一个能够将json对象存储在mongodb中，然后以相同状态检索它。所以我想要json看起来如下：

{'id': '1', 'url': 'aaa.com', 'images_paths': ['img.png'], text_path: 'text.txt'}

还有一个将是REST API的json输出

{'id': '1', 'url': 'aaa.com', 'images_paths': ['localhost/tasks/1/images/img.png'], text_path: 'localhost/tasks/1/text/text.txt'}

根据DDD原则，我认为这两个都是json序列化方法，应该位于基础结构层中，对吗？从DDD角度来看，它们是否正确？两者都应该被称为json序列化吗？

我也不确定测试。流行的序列化测试是：

assert task_from_json(task_to_json(task)) == task

但是我无法针对REST API json案例进行此类测试

Answer 1

从干净的体系结构角度来看，业务层您不必关心如何在数据库中存储对象或如何在Web中表示对象。

您的业务层应该知道有一个接口，负责存储和提取对象

interface TaskStorage {
    fun save(Task)
    fun fetchTaskById(id: Integre): Task
}

和网页表示界面

interface SomeView {
    fun render(Task)
}

只有数据层会知道Task应该转换为json表示形式并存储到Mongo。并且只有视图层知道Task将被表示为json。

当然，您应该有2个从Task到json的转换器：

数据访问层上的一个
在表示层上一个。

主要思想是：域层不应该知道任何Json表示形式

json序列化方法应如何处理应为链接的attrs？

1 个答案: