タグ

2018年5月30日のブックマーク (6件)

  • [DDD]ドメイン駆動設計の定義についてEric Evansはなんと言っているのか - Qiita

    DDD連載記事 なぜDDD初心者はググリ出してすぐに心がくじけてしまうのか ドメイン駆動設計の定義についてEric Evansはなんと言っているのか モデルでドメイン知識を表現するとは何か ドメイン駆動設計で実装を始めるのに一番とっつきやすいアーキテクチャは何か ドメイン駆動 + オニオンアーキテクチャ概略 ドメイン駆動設計について、「どうやって実装するのさ?」の前に、まずは定義について認識合わせをしたいと思います。 背景 「ドメイン駆動設計とは何か?」 ドメイン駆動設計について興味を持った時に、一番最初に疑問に思うのがこれですね。 ところが、ググって見ると結構いろんなサイトでいろいろな書きぶりをしているんですよね・・・。 「顧客と開発者が業務を戦略的に理解し、共通の言葉を使いながらシステムを発展させる手法」 ドメイン駆動設計のメリットと始め方(Codezine記事) 「厳しい現実の中で、

    [DDD]ドメイン駆動設計の定義についてEric Evansはなんと言っているのか - Qiita
  • React NativeをWebに持ってくることの意味 - ナカザンドットネット

    ブラウザはGUIアプリケーションプラットフォームではない Flexboxについて React DOMはGUIアプリケーションフレームワークではない React NativeはGUIアプリケーションプラットフォームの抽象である React Native for Webがブラウザに持ち込んだもの コンポーネントが便利 スタイル周りも良い感じ TouchableOpacityでタップ表現もラクラク 他にもいろいろあるけど プロダクション事例が強すぎる 作者のnecolasも語ってた まとめ 余談:React系のアプリケーションフレームワーク React Native for Webは、React NativeをWebに持ち込む試みです。 しばしば、こういった試みに対して「わけがわからない」「末転倒である」といった意見を見かけますが、筆者は妥当な試みであるという印象を持っています。ちょっと頭の中

    React NativeをWebに持ってくることの意味 - ナカザンドットネット
  • Dockerのネットワークを理解するために覚えたことまとめ - Carpe Diem

    概要 Dockerのネットワーク周りを勉強していると、 docker0 仮想ブリッジ VXLAN link機能 など色んな要素が出てくるのですが、ちゃんと理解していないとすぐ忘れるため一度しっかり学んでみました。 今回はその時に疑問に思ったことをまとめてみました。 環境 docker 1.11.2 構成 マシン IP 役割 ホスト 192.168.33.10 Dockerホスト docker0 172.17.0.1 仮想ブリッジ nginx1 172.17.0.2 コンテナ1 nginx2 172.17.0.3 コンテナ2 事前知識 以下の知識があると学ぶ上で非常に助かります。 ブリッジ 第2層でMACアドレスで判別して転送 3 Minutes Networking No.17 ルータ 第3層でIPで判別して転送 3 Minutes Networking No.28 NAT、NAPT、IP

    Dockerのネットワークを理解するために覚えたことまとめ - Carpe Diem
  • Railsアプリケーションでフォームをオブジェクトにして育てる - クックパッド開発者ブログ

    ユーザーエンゲージメント部の諸橋 id:moro です。 わたしはずっと、ユーザー登録やログイン周りという、サービス的には基盤的なところ、技術スタック的にはアプリケーション寄りのところに取り組んできました。関連する話を何度かこの開発者ブログにも書いています。 ユーザー基盤を作り直しながらRailsでのサービス層に向き合う 巨大なWEBアプリケーションに巨大な変更を取り入れるためにやったこと この記事で触れている「電話番号による登録」について、チームメンバーが別の側面を紹介してくれています。 今日はそのあたりの開発を通じて考えた、Railsアプリケーションでのフォームオブジェクトやサービス層といったものが何であるか、という問いに対する、現在の自分のスタンスを紹介します。 サービス層、サービスオブジェクト、フォームオブジェクト もともと Railsは Web 画面から DB 構造までをあえて密

    Railsアプリケーションでフォームをオブジェクトにして育てる - クックパッド開発者ブログ
    oasis440
    oasis440 2018/05/30
    “7 Patterns to Refactor Fat ActiveRecord Models”
  • git rebaseを初めて使った際のまとめ - Qiita

    環境 とくになし はじめに 今までrebaseを使ったことが無かったのですが、コードレビューを依頼した際に「マージコミットが邪魔で見づらい…」と言われてしましました。「ログを綺麗にするため」にrebaseについて学んだことのまとめです。 まず、ログがどのように綺麗になるのかを以下に説明します。 mergeを使った場合のログ(あまり綺麗ではないログ) 例えば下図のようなブランチが存在し、自分が今featureにいるとします。この状況でbugfixが入った最新のdevelopを取り込みたいと考えているとします。 マージを使って取り込みます。 無事取り込むことができました。しかし「git log」をしてみると時系列順に並ぶためfeatureのコミットが飛び飛びになってしまい、すごく見づらくなっています。 rebaseを使った場合のログ 最初の状況は先程と同じです。 rebaseを使って取り込んで

    git rebaseを初めて使った際のまとめ - Qiita
    oasis440
    oasis440 2018/05/30
  • 7 Patterns to Refactor Fat ActiveRecord Models

    When teams use Code Climate to improve the quality of their Rails applications, they learn to break the habit of allowing models to get fat. “Fat models” cause maintenance issues in large apps. Only incrementally better than cluttering controllers with domain logic, they usually represent a failure to apply the Single Responsibility Principle (SRP). “Anything related to what a user does” is not a

    7 Patterns to Refactor Fat ActiveRecord Models