原文在此，续前……

——–翻译分隔线——–

在 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…)

这篇文章虽然不长，但是很有趣。看到好几天了，一直都没空翻译。抽空翻译出来，这应当算是英文“标题党”和“高级黑”吧。

原文不好读，也没什么特别的；不过如果是为了强化学习 Golang 的信心，值得看看。

原文在此：http://aeronotix.pl/blog/go-is-boring

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

无聊的 Golang

Go 没什么新鲜的，也没什么特别的。你在看到 Go 之前都遇到过了。是的，我也是这么认为的。不过你所没见过的是所有这些都集中在一个语言中，产生了一个 TMD 超级有用的核心。

(more…)

上个星期，我写了篇《Function call by name in Golang》。由于是英文的，所以被人诟病（说谁，谁知道！）。好吧，现在用中文重新写一遍。

Golang 中的函数跟 C 的一样，是个代码块，不过它可以像其他类型那样赋值给一个变量。

如果你对函数不熟悉，《Codewalk: First-Class Functions in Go》应该是个不错的起点。已经有所了解？那么继续吧！

首先，来看看这段 PHP 代码：

function foobar() {
    echo "Hello Golang\n";
}
$funcs = array(
    "foobar" => "foobar",
    "hello"  => "foobar",
);
$funcs["foobar"]();
$funcs["hello"]();

它会输出：
mikespook@mikespook-laptop:~/Desktop$ php foobar.php
Hello Golang
Hello Golang

 (more…)