[翻译]在 Go 应用中使用简明架构(5)

原文在此,续前…… ——–翻译分隔线——– 在 Go 应用中使用简明架构(5) 基础层 就像上面提到的,我们的存储认为“数据库”是一个可以用 SQL 请求发送或接收数据行的抽象。它们不关心基础构建的问题,例如链接到数据库,或使用哪个数据库。这是在 src/infrastructure/sqlitehandler.go 中完成的,高层次的 DbHandler 接口是通过调用低层次的功能来实现的:

[翻译]在 Go 应用中使用简明架构(4)

原文在此,续前…… ——–翻译分隔线——– 在 Go 应用中使用简明架构(4) 接口层 关于这点,必须说,所有东西都得有编码智慧,不论是真实的商业还是我们的应用用例。让我们看看对于接口层的代码这意味着什么。不像在各个内部层次中,所有代码都属于一个逻辑,接口层是由若干独立的部分构建而成。因此,我们将这个层次的代码拆分为若干个文件。 由于我们的商店要通过 Web 访问,就从 Web 服务开始吧:

[翻译]在 Go 应用中使用简明架构(2)

原文在此,续前…… ——–翻译分隔线——– 在 Go 应用中使用简明架构(2) 架构实现 首先来实现领域层。之前已经说过,应用和其用例将完全可用,但是这不是一个完整的商城。因此,定义领域的代码应当足够短小,这样正好可以放在一个文件中:

[翻译]在 Go 应用中使用简明架构(1)

原文在此,很长,好文,不解释。不快点翻译,就翻译不完了。 —————-翻译分隔线—————- 在 Go 应用中使用简明架构(1) 关于这篇文章 我想通过展示如何将 Bob 大叔的简明架构使用到 Go 应用,来向这个概念做一些贡献。这里并未对 Bob 大叔的博文进行过多的修改,因此阅读他的文章是理解我的内容的先决条件。 其中,他主要描述了依赖原则,也就是软件的不同部分组织成环的形式一个套一个的应用到架构中。“……也就是说代码的依赖应当是内敛的。内环对外环的一切都一无所知。尤其是那些定义在外环的名字,不应当在内环的代码中出现。包括函数、类、变量或任何命名的软件模型。” 我认为,依赖原则是构建可对框架、UI或数据库进行局部测试并解藕的软件系统的最为重要的条件。当遵循这个条件时,将得到一个有着明确关注分离的低耦合系统。