Goのクリーンアーキテクチャで参考になりそうなものはじめに Goでクリーンアーキテクチャっぽく実装したいモチベーションがあり、そのためにはコードを読むのが一番だと思ったので、参考にしていったリポジトリをまとめてみます。 観点としては スター数が比較的多いもの（400以上） READMEにアーキティクチャについての考えが明記されているもの を中心にピックアップしました。 Goの実装で参考にしたリポジトリ Goとは関係ないかもしれないが参考にしたリポジトリ おわりに 何かの参考になれば幸いです。
go言語でクリーンアーキテクチャっぽいもの | IIJ Engineers Blog
IIJ プロダクト本部 応用開発課 所属。2015年に新卒入社。webアプリケーションの実装・運用を中心にやりたいことがあれば何でも手を出してみる所存です。 【IIJ 2018 TECHアドベントカレンダー 12/6（木）の記事です】 はじめに 最近go言語でDDDやクリーンアーキテクチャを実践してみたという記事を多く目にするようになりました。 自分が半年ほど前に初めてgoでサーバーを実装することになった際も、先人達の記事のおかげでどうにか形にすることができました。 特に pospome さんの Goのサーバサイド実装におけるレイヤ設計とレイヤ内実装について考える はとても参考にさせていただきました。 （勝手に出してしまって申し訳ありません。） 恩返しというわけでは無いですが、自分なりに消化して実装したものを紹介したいと思います。サンプルコードは実際のコードを元にでっち上げて書いているので
ソースコードで理解するクリーンアーキテクチャ - Sansan Tech Blog
はじめに こんにちは。プロダクト開発部の荒川です。 これまで最年少を謳っていましたが、ついに新卒の子にその座を奪われてしまいました。とても残念です。 さて今回のテーマは、皆さんお馴染みクリーンアーキテクチャ（Clean Architecture）です。 クリーンアーキテクチャは一時期流行し、その流れに乗って私もある程度の理解はしていました。 しかし、それはあくまでも感覚的な理解であって、他人に説明や良さを語れるレベルまで自分の中で落としこめていませんでした。 そこでより具体性のあるソースコードを読み込むことで、アーキテクチャへの理解を深めたいと思います。 クリーンアーキテクチャとは？ クリーンアーキテクチャの定義や解説に関しては、ネット上にいくらでも公開されているので、このエントリでは詳しく話しません。 私自身が勉強に使った書籍やサイトを記事末尾の「参照」に掲載しているので、そちらを参考に
実践クリーンアーキテクチャ with Java
この記事について こちらの記事はクリーンアーキテクチャの Java 実装による解説記事です。 MVC フレームワークに組み込むために一部変更している部分もあります。 それをふまえてご覧ください。 講演内容が @IT さまに記事にしていただけました。 あわせてご参照ください。 https://www.atmarkit.co.jp/ait/articles/1907/08/news002.html クリーンアーキテクチャよりも軽量で無理なく導入しやすいアプリケーションアーキテクチャパターンを考案しました。 https://nrslib.com/adop/ スライド JJUG CCC 2019 Spring での発表資料です。 この発表をするにあたって記事を書くことにしました。 YouTube YouTube でこちらの解説を行いました。 その他解説もしています。もしよろしければチャンネル登録を
実践DDD アーキテクチャ - Qiita
はじめに 実践DDD本の第4章で扱われるアーキテクチャについて整理する。 また、以下に著者によるJavaとC#のサンプルがGitHubに公開されているので、サンプル実装を参考にするとよいと思われる。 IDDD Javaサンプル IDDD C#サンプル DDDにおけるアーキテクチャ DDDの利点は、特定のアーキテクチャに依存しない。 品質要求がどのアーキテクチャを採用するかの原動力になるべきであり、リスク駆動の手法として有益。 何らかのアーキテクチャを採用するに当たって、機能要件（ユースケースやユーザーストーリー、ドメインモデルに固有のシナリオなど）が分からなければ、適切なアーキテクチャを選択できない。 以上を踏まえて最適な選択をすることが目標。 レイヤ化アーキテクチャ N層システムのアーキテクチャであり、いわゆる2層アーキテクチャ（クライアント・DB）や3層アーキテクチャ（webサーバー・
実践クリーンアーキテクチャ │ nrslib
YouTube での解説 YouTube にて Java コードをベースに解説を行いました。 コードの雰囲気は C# とほとんど同じなので参考になるかと思います。 もしよければご覧ください。 Java コードの記事リンク：https://nrslib.com/clean-architecture-with-java/ その他解説もしています。もしよろしければチャンネル登録をお願いいたします。 Qiita 版 Qiita に CUI や GUI 向けのクリーンアーキテクチャの記事を書きました。 ボブおじさんのクラス図を模したものです。 Web とはまた異なった実装になるので、もしよければ合わせてご参照ください。 https://qiita.com/nrslib/items/a5f902c4defc83bd46b8 さらに PHP の Laravel 版も作ってみました。 https://qi
Laravelで実践クリーンアーキテクチャ - Qiita
この記事を書くにあたって Laravel について色々サポートしてくれた皆さまに向けてお礼申し上げます。ありがとうございました。 本記事はクリーンアーキテクチャに対する理解を深めていただくために、「実践クリーンアーキテクチャ」の内容を Laravel で実装して解説するという内容になっています。 記事のゴールは「クリーンアーキテクチャに対する理解を深めてもらう」というものです。つまり、この実装の形は一例に過ぎません。 はじめに 皆さんクリーンアーキテクチャはご存知でしょうか。 そう、こんな図のアレです。 The Clean Architecture: https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html クリーンアーキテクチャといえばこちらの象徴的な図をまずは思い浮かべるでしょう。 この図を
ドメイン駆動設計のエンティティとクリーンアーキテクチャのエンティティ
概要 ドメイン駆動設計の有名な用語にエンティティというものがあります。 ほとんどドメイン駆動設計の代名詞のひとつと言っても過言でないほどの有名さを誇るこちらの用語ですが、なんとクリーンアーキテクチャにもまったく同じエンティティという用語が出てきます。 このエンティティという用語は名前こそ同じではありますが、実は完全に同じものを指しているわけではありません。 とはいえまったく違うものである、というわけでもありません。 要するにややこしい。 この記事はこのややこしい用語について、ドメイン駆動設計とクリーンアーキテクチャのそれぞれのエンティティが何を指していて、それがどのように異なっているのかについてを解説します。 それぞれのエンティティ そもそもエンティティとは何でしょうか。 英和辞典を引くとエンティティとは「存在［実在］物」といった意味が出てきます。 これはかなり抽象的な意味です。 つまり、
持続可能な開発を目指す ~ ドメイン・ユースケース駆動（クリーンアーキテクチャ） + 単方向に制限した処理 + FRP
この記事は、開発を持続可能にできるようなアーキテクチャとその適用方法を考察するものです。 骨子はできていますが、実装経験をフィードバックして詳細を若干変更するかもしれません。 勉強不足な点もあるので、意見を歓迎します。 開発においてよくある問題点 ビジネスロジックの本質が何だったか見失う。ソースコードのどこまでが業務上の関心で、どこからがそれを実現するための技術上の関心か分からなくなる。 入出力双方向の処理が散在して処理が追い切れなくなる。特にイベント処理でどこに飛ぶかわからないコールバック地獄になる。 初期化・つなぎ込み・統合者的オブジェクトが小さな機能単位で生まれて統一感が無くなる。 状態を持つ値が大量に散在して副作用を起こしバグを生む。 これらの問題の結果、小さな単位ごとに個人のノウハウで"良い"設計がされ、機能を追加しようとしたときにどういう方針で行えばよいか分からなくなる。 解決
ヘキサゴナルアーキテクチャ(Hexagonal architecture翻訳)
Alistair Cockburn による Hexagonal architecture の翻訳です。PoEAAで言及されていることから、2002年ごろにはすでにC2 Wikiにページがあった模様。似たようなアーキテクチャである クリーンアーキテクチャ も翻訳したので参考にしてください。 この記事は著者から許可を得て公開しています。Thanks to Alistair Cockburn! 目次 パターン: Ports and Adapters (構造に関するパターン) 意図 動機 解決法の本質 構造 サンプルコード ステージ1: FIT アプリ 定数をモックデータベースとして ステージ2: UI アプリ 定数をモックデータベースとして ステージ3: (FITまたはUI) アプリ モックデータベース 応用ノート 左右の非対称性 ユースケースとアプリケーションの境界 ポートはいくつ? 既知の用
CQRSとイベントソーシングの使用法、または「CRUDに何か問題でも？」 | POSTD
書き込みと読み込みのどちらに力を入れているかは、ストレージエンジンによって異なります。たとえば昔ながらのリレーショナルデータベースは、外部キーなどの制約を使ってデータの整合性をうまく制御できるようになっています。一方でNoSQLデータベースは、スループットとスケーラビリティを確保するために、そういった組み込みのガードレールをはずしてしまいました。データ層においても、どちらか一方に特化した最適化をすることがあります。たとえば、あらかじめ計算済みの値を保持しておけば、「一日あたりのサイト訪問者数」などの読み込み操作を効率よく行えるでしょう。ストレージソリューションのメーカーはどこも、「うちのプロダクトならあらゆるニーズを満たせます」などと自社製品の機能を自慢します。しかし実は、昔ながらのCRUDモデルに沿ってストレージエンジンを選んでデータ層を設計した時点で、さまざまな関心事の間で何らかの妥協
実践DDD本 第4章「アーキテクチャ」 ～レイヤからヘキサゴナルへ～
前回記事：IDDD本の第3章「コンテキストマップ」の解説 本稿で紹介するアーキテクチャの種類 エバンズ本では、DDDのアーキテクチャは「レイヤアーキテクチャ」を中心に紹介していました。これに対してIDDD本では「ヘキサゴナルアーキテクチャ」を提唱しています。さらにヘキサゴナルアーキテクチャと関係が強い「サービス指向（SOA、REST）」「コマンドクエリ責務分離（CQRS）」「イベント駆動アーキテクチャ（パイプ＆フィルター、長期サーガ、イベントソーシング）」といった概念やアーキテクチャ方式についても取り上げています。 特定のアーキテクチャに依存しないDDD DDDは特定の技術に依存していないため、自由にアーキテクチャを選択することができます。アーキテクチャの選定においては、構築するシステムに求められる「機能要求（ユースケース、ユーザーストーリー、ドメインモデルのシナリオ等）」と「品質要求（性
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「実践ドメイン駆動設計」 から理解するDDD (2018年11月)
集約の設計と実装
ドメインモデル中心のアーキテクチャ | GuildWorks Blog
ドメイン駆動設計とオニオンアーキテクチャ