並び順

ブックマーク数

期間指定

  • から
  • まで

1 - 3 件 / 3件

新着順 人気順

"Clean Architecture"の検索結果1 - 3 件 / 3件

  • 【技術書】最近読んでよかった本まとめ - Qiita

    はじめに エンジニア歴1年目の頃に「新人エンジニアの自分がおすすめする技術書ランキング2022春」という記事を投稿したのですが、エンジニア歴も4年目に入ったということで、改めて最近読んで良かった本を紹介しようと思います。 前回の記事とは違い、ランキングづけはせずにビジネス紹介しようと思います。 ビビッとくるものがあればぜひ手に取ってみてください。 なお今回は紹介しませんが、いまだに1番読んでよかったと思っている技術書はオブジェクト指向設計実践ガイドです。最強です。 プロダクトマネージャーのしごと第二版 感想 仕事でプロダクトマネージャーっぽい動きはするけれど、実際に何したら良くて何をする人がPMなのかさっぱりわからんってなってた時に買いました(同じ状況の人がもしいればおすすめです) PMの仕事の輪郭は多少見えるようになったと思います。有り体な言い方をするのであればPMへの解像度が上がりまし

      【技術書】最近読んでよかった本まとめ - Qiita
    • [golang] 言語仕様から見るunittestとClean Architectue - Qiita

      概要 GolangでServiceを作る中で感じたunittestおよびClean Architectureという壁についてまとめてみた。 Golangにおけるテストとモック 『Unittestのために、モジュール間参照はインターフェースを使わなければならない』 Golangでunittestを書こうと思ったとき、困るのがモックだ。 例えばJavaであれば、どんなClassもそれを継承したClassを(無理やり)作る事ができるので、対象のコードの中の依存オブジェクトをモックに差し替える事ができる。 例えばPythonやJavaScriptであれば、そもそも型がないので自由にモックに差し替える事ができる。 ところが、Golangでは、

        [golang] 言語仕様から見るunittestとClean Architectue - Qiita
      • サーバクライアント型のシステムでGraphQLの採用を避けた方が良いと思う理由 - Qiita

        自ブログからの引用です。 はじめに GraphQLは非常に高機能なツールである一方、万能が故に本来必要でないケースでも気軽に利用されている印象を受けます。 筆者は同じ組織で同じ目的のために構築されたサーバとクライアントの通信において、GraphQLを採用すべきでないと考えており、本記事ではそのポイントを整理していきます。 なお、本記事ではこのような1対1型のシステムをサーバクライアント型とよびます。 念のために記載しますが、GraphQLは素晴らしい技術であり、本記事はGraphQLを批判するものではありません。 TL;DR (本当の意味で) Code Firstな開発を進めることが難しい サーバクライアント型のシステムでは概念的に両者は一体であるため、両者間の結合を抽象化しない方がよい ドメイン駆動設計を実践するに当たって、ドメインから視点をブラし、モデル駆動開発を阻害する要因となる 開

          サーバクライアント型のシステムでGraphQLの採用を避けた方が良いと思う理由 - Qiita
        1