タグ

architectureに関するlilpacyのブックマーク (25)

  • 【Go + レイヤードアーキテクチャー】DDDを意識してWeb APIを実装してみる

    更新(2019年10月30日)初回投稿から3ヶ月経ちました。 この3ヶ月で新しく得た知見を基に、内容を一部アップデートしました。 今回やることGoのディレクトリ構成についていろいろと調べる中で、 こちらの資料 がとても分かりやすかったので、 今回はこちらを参考にGoでWeb APIを作っていきたいと思います。 加えて、プロジェクトでは、DDD と レイヤードアーキテクチャー を取り入れます。 (内容はほぼレイヤードアーキテクチャになってしまいましたが…) DDD については、「DDD を Go とレイヤードアーキテクチャでやるなら、こんな感じかな?」という個人の見解レベルです。 パッケージ構成の参考になれば幸いです。 (ですので、ドメインモデルは重度のドメイン貧血症に陥っていますw) 釣りタイトルみたいになっちゃっててすみません🧝‍♀️ 環境MacOS Mojave 10.14.6Go

  • 変更に強いアーキテクチャについてIT業界19年目の僕が超ザックリ説明する - Qiita

    この記事は、設計・アーキテクチャ Advent Calendar 2018 の第7日目の記事である。 はじめに この記事では、IT業界19年目の僕が実践している変更に強いアーキテクチャについて、出来るだけ難しい表現を避け、教科書的なありきたりな内容ではなく現場の肌感覚に近い切り口で「超ザックリ」な解説を試みてみようと思う。 普段自分がよく用いている実装パターンの紹介ともいうべきかも知れない。 この記事で説明すること いざ「変更に強いアーキテクチャとは」とズバリ訊かれても、一概に「これだ!」という答えはない。 プログラミング言語や、フレームワークによっても条件が異なるし、利用可能な技術や開発チームの特性、業務要件や運用要件の特性によっても様々であるし、インフラや開発プロセスまで含めて考えると考慮すべきことは無限にある。 ここでは主にソフトウェアの構造という観点から、"変更に強い" ということ

    変更に強いアーキテクチャについてIT業界19年目の僕が超ザックリ説明する - Qiita
  • ネットワーク越しリトライ考 - その手の平は尻もつかめるさ

    ここ最近では何らかのインターネットサービスを構築・運用するにあたって、ネットワーク越しのリトライを考えることは避けられなくなりつつあります。 micro services のようなアーキテクチャを採用している場合はサービス間のメッセージのやり取りはまず失敗する前提 (つまりリトライをする前提) で組む必要がありますし、たくさんのクライアントがいてそのクライアントが定期的に何かを処理してセントラルにデータを送ってくる IoT のようなシステムを構築する時もその処理のリトライをよく考える必要があります。 というわけで「ネットワーク越しのリトライ」についてここ最近考えていることをざっくりと書き留めるものであります。 前提 リトライをする側をクライアント、リトライを試みられる側をサーバと呼称します リトライにおいて、サーバおよびネットワークはクライアントよりも弱者です クライアントはリトライをコン

    ネットワーク越しリトライ考 - その手の平は尻もつかめるさ
  • レイヤードアーキテクチャ - kawasima

    POSAでの定義 レイヤードアーキテクチャを、体系だって書いたのは「Pattern-Oriented Software Architecture, Volume 1, A System of Patterns」だろう。まずはその原典に立ち返って、レイヤードアーキテクチャとは何かをみてみる。 コンテキスト ソースコードの変更がシステム全体に波及させたくない。それが1つのコンポーネントに閉じられ、他に影響を与えないようにすべきだ。 インタフェースは安定している。標準化団体によって規定されている場合もある。 システムの一部は交換可能である。コンポーネントはシステムの他の部分に影響を与えることなく、実装を入れ替えることができる。 現在設計しているシステムと同様の下位レイヤの課題をもつ他のシステムを、将来構築することがあるかもしれない。 理解のしやすさと保守性のために同じ責務はグルーピングしておきた

    レイヤードアーキテクチャ - kawasima
  • Clean ArchitectureとEffで変更に強いAPIを設計する

    モジュラモノリスで表現する複雑なドメイン領域と境界 https://speakerdeck.com/showmant/expressing-complex-domain-regions-and-boundaries-with-modular-monoliths PofEAAで考えるSaaSバックエンドの作り方 https://speakerdeck.com/dnskimo/pofeaadekao-erusaasbatukuendofalsezuo-rifang The Clean Architecture https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html Freer Monads, More Extensible Effects http://okmij.org/ftp/Haskell/

    Clean ArchitectureとEffで変更に強いAPIを設計する