原文在此，续前……

——–翻译分隔线——–

在 Go 应用中使用简明架构（5）

基础层

就像上面提到的，我们的存储认为“数据库”是一个可以用 SQL 请求发送或接收数据行的抽象。它们不关心基础构建的问题，例如链接到数据库，或使用哪个数据库。这是在 src/infrastructure/sqlitehandler.go 中完成的，高层次的 DbHandler 接口是通过调用低层次的功能来实现的：
(more…)

原文在此，续前……

——–翻译分隔线——–

在 Go 应用中使用简明架构（4）

接口层

关于这点，必须说，所有东西都得有编码智慧，不论是真实的商业还是我们的应用用例。让我们看看对于接口层的代码这意味着什么。不像在各个内部层次中，所有代码都属于一个逻辑，接口层是由若干独立的部分构建而成。因此，我们将这个层次的代码拆分为若干个文件。

由于我们的商店要通过 Web 访问，就从 Web 服务开始吧：

(more…)

原文在此，续前……

——–翻译分隔线——–

在 Go 应用中使用简明架构（3）

用例层

现在来看看用例层代码，同样，它刚刚好能放在一个文件中：

(more…)

原文在此，续前……

——–翻译分隔线——–

在 Go 应用中使用简明架构（2）

架构实现

首先来实现领域层。之前已经说过，应用和其用例将完全可用，但是这不是一个完整的商城。因此，定义领域的代码应当足够短小，这样正好可以放在一个文件中：

(more…)

原文在此，很长，好文，不解释。不快点翻译，就翻译不完了。

—————-翻译分隔线—————-

在 Go 应用中使用简明架构（1）

关于这篇文章

我想通过展示如何将 Bob 大叔的简明架构使用到 Go 应用，来向这个概念做一些贡献。这里并未对 Bob 大叔的博文进行过多的修改，因此阅读他的文章是理解我的内容的先决条件。

其中，他主要描述了依赖原则，也就是软件的不同部分组织成环的形式一个套一个的应用到架构中。“……也就是说代码的依赖应当是内敛的。内环对外环的一切都一无所知。尤其是那些定义在外环的名字，不应当在内环的代码中出现。包括函数、类、变量或任何命名的软件模型。”

我认为，依赖原则是构建可对框架、UI或数据库进行局部测试并解藕的软件系统的最为重要的条件。当遵循这个条件时，将得到一个有着明确关注分离的低耦合系统。
(more…)