タグ

関連タグで絞り込む (0)

  • 関連タグはありません

タグの絞り込みを解除

Programmingとgolangと設計に関するclavierのブックマーク (5)

  • DDDを実践するためのリポジトリ層の設計(Go言語による例)

    The Go gopher was designed by Renée French. Illustrations by tottie. はじめに この記事は、ドメイン駆動設計(DDD)の中核概念である「リポジトリ」についての理解を深めることを目的としています。リポジトリの基的な役割と重要性を確認し、Go言語での実装の例を紹介します。 前提 リレーショナルデータベースからデータを取得(更新)するアプリケーションを想定しています サンプルコードは Go 言語で書かれています リポジトリとは まずは、リポジトリの定義を確認してみましょう。 リポジトリパターンとは: リポジトリは、データベースから取得したデータを構造体にマッピングし、ドメインオブジェクトにアクセスするためのインターフェースを提供します。 これは、一般的なリポジトリの理解と相違ないですね。次に DDDの文脈で、より詳しい定義をみ

    DDDを実践するためのリポジトリ層の設計(Go言語による例)
  • 2023年の Go での気づきに思いを馳せて構築するオレオレ Go サーバープロジェクトレイアウト

    2023 年は念願叶い業務でも趣味でも Go を触ることができました。 そんな 2023 年での Go での気づきに思いを馳せ、タスク管理をするような簡単なサーバーを構築しそのプロジェクトレイアウトをご紹介してみます。 気づきといっても読む方にとっては当たり前のことかもしれません。 また、プロジェクトレイアウトはこれが正義だとは思っていません。紹介するレイアウトは業務では使っていないです。運用などもまともにしたことはありません。私がそこそこの規模のサーバーを新規で構築するならこんな風にしようかなって記事です。 気づき interface を満たすためのコードって VSCode で自動生成できたんだ よくおまじないとかファクトリー関数の戻り値とかで構造体が interface を満たしているかどうかを確認することがあるかと思います。 package main import "context"

    2023年の Go での気づきに思いを馳せて構築するオレオレ Go サーバープロジェクトレイアウト
  • 少しずつ育てるGo言語のプロジェクト構成

    23/9/21追記:この記事を読む前に ついにGoチームから、プロジェクト構成に関するガイドが公開されました! 記事を読んでくださることも大変嬉しいですが、ぜひこちらのガイドもご一読ください! この記事は何 Go言語を書いたことがある方も、興味はあるけど触ったことがない方もこんにちは。 Goに限った話ではないと思いますが、ガリガリコードを書いていて、あるタイミングで気になるのがプロジェクト構成(ここではディレクトリ構成の意図)ではないでしょうか? それを裏付けるかのように、Go界隈では以下のリポジトリが話題に上がることがあります。Star数すごいですね😇 リポジトリ名から公式感が漂いますが、そういう訳ではないのがミソです。 こちらのリポジトリ冒頭にも記載されていますが、次の点に留意する必要があるでしょう。 これは、Goアプリケーションプロジェクトの基的なレイアウトです。これは、コアと

    少しずつ育てるGo言語のプロジェクト構成
  • 強い思想: Go を Web 開発に採用する上で

    フラットパッケージは正義か? 私が SNS で何度か言及した以下の記事がある。 フラットパッケージ戦略は,確かに Go文化圏においては一定の支持を集めている。Go の公式リポジトリや有名ライブラリなんかも,Java などの言語に比べたらずっとパッケージ階層が浅く,ネストしていないものが多いと思う。 しかし,それも 「コードベースを小さく保つ」 を大前提としていることを忘れてはならない。 DDD やクリーンアーキテクチャといった言葉が飛び交うぐらいの規模であれば,パッケージを切ることに関して後ろめたさを感じる必要はない。 むしろ,大きなコードベースが誕生することが開発初期から簡単に予見できるような状況で, YAGNI という言葉に甘んじて設計を放棄するのは極めて悪手であると私は断言する。身を以て失敗を経験した私の口から伝えたい。

    強い思想: Go を Web 開発に採用する上で
  • Goの構造体の使われ方の設計 | フューチャー技術ブログ

    Goで構造体を設計する場合、オブジェクト指向的な「型ごとの責務の分担」以外に、「どのように使われるものか」を考える必要があります。 ポインタで扱うのか? 値として扱うのか? 両方許可するのか? 値として扱える場合にimmutable(変更不可能)なオブジェクトとするのか、mutable(変更可能)なオブジェクトとするのか 値として扱える場合にゼロ値での動作を補償するかどうか 他の言語で言うと、C#の構造体とクラスの違い、C++のデフォルトコンストラクタあたりに頭を悩ませたことがある人にはおなじみかもしれませんが、Goでもいくつか考慮が必要になります。 ポインタ型として扱う必要があるケースまず最初に決断できる方針としては、ポインタ型でのみ扱うかどうかです。 内部にスライスやmap、ポインタなどの参照型な要素を持っていれば、基的にポインタ型でのみ扱う構造体になります。これらの要素を持っていた

    Goの構造体の使われ方の設計 | フューチャー技術ブログ
  • 1