RestAPIをCleanArchitectureで実装する際のreq/resの持ち回りについて - Qiita
※zennに投稿した記事の転載です。 概要 提題の通り、CleanArchitectureに則ってRestAPIを実装する場合に、 以下の2点に迷ったので、結論とそれに至るまでの考えを書き残しています。 requestオブジェクトはどのレイヤーまで持ち回すべきか？ responseオブジェクトはどのレイヤーで生成するべきか？ 背景 よくあるシンプルなCRUDアプリを実装する際、以下のような処理を実装するとします。 この場合、controller→usecase→repositoryとMVCやレイヤーアーキテクチャ的にパッケージを掘っていき処理を実現して行くのは誰もが違和感なく考えられることですが、 今回はCleanArchtectureを採用しているため、controller → usecase ← repositoryのような依存関係で実装する必要があります。 ※詳しくは後述するClea
DDDを意識しながらレイヤードアーキテクチャとGoでAPIサーバーを構築する - Qiita
今の現場で初めてDDDに触れたので、よく採用されるアーキテクチャとしてレイヤードアーキテクチャを自分で0から実装してみました。 言語もよくセットで採用されているGoを採用してみました。 この記事の目的 0から実装して体系的にDDDとレイヤードアーキテクチャを学ぶ DDDに触れたことがない方にもわかりやすく説明する そもそもDDD(ドメイン駆動設計)とは 要約(引用)すると「ドメインの知識に焦点を当てた設計手法」です。 たとえば電子カルテのシステムを例に取ってみます。 電子カルテには患者情報や手術の予定、入院ベッドの空き具合などの概念があると考えられます。 医療関係者ではないソフトウェアエンジニアは実際につかうユーザー（医療関係者）が直面している問題やドメイン(領域)の概念、事象を理解することが必要です。 それらを理解し、ソフトウェアに落とし込む。落とし込み続けることを実践する開発手法です
今すぐ「レイヤードアーキテクチャ+DDD」を理解しよう。（golang） - Qiita
とはいっても記事を読み終わるのに三時間くらいかかる気がします。 対象読者 レイヤードアーキテクチャ+DDDの実装に困っている方 バックエンドエンジニアを目指す学生 APIサーバを開発したことがある方 はじめに アーキテクチャは学習コストが高いと言われています。その要因の一つとして考えられるのはアーキテクチャの概念を学んだとしても、アーキテクチャの細かい部分は実装者に左右されるので、ネット上にあるプログラムは概念とはズレがあるので混乱しやすいことだと思います。それに加えて他のサイトを参考にした時もやはり実装者による違いで混乱してしまうからです。 したがって、概念とズレがある部分はしっかり言及したうえで解説することが良いと思います。 アーキテクチャを採用する意味 レイヤ間が疎結合になるため、ユニットテストが行いやすいこと。 責務がはっきりしているので、保守性が高いこと。 途中からフレームワーク
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Repositoryによる抽象化の理想と現実/Ideal and reality of abstraction by Repository