タグ

関連タグで絞り込む (79)

タグの絞り込みを解除

Qiitaとドメインに関するkyo_agoのブックマーク (19)

  • [翻訳] Shopifyにおけるモジュラモノリスへの移行 - Qiita

    こんにちは、食べログシステム本部長の京和です。 本エントリでは Shopify の Engineering Blog から、Kirsten Westeinde による「Deconstructing the Monolith: Designing Software that Maximizes Developer Productivity」を翻訳して掲載します。 食べログではユーザーや飲食店に価値を届けるスピードを最大化するべく、マイクロサービス化などをはじめとしたこれまでの組織やアーキテクチャを刷新するための取り組みを始めています。しかし、マイクロサービスはアプリケーションアーキテクチャとインフラアーキテクチャが複雑に絡み合ったシステムで技術的難易度が非常に高く、適切に構築できなければ「分散されたモノリス」と呼ばれるアンチパターンに陥ります。1 Shopifyではマイクロサービスではなく、

    [翻訳] Shopifyにおけるモジュラモノリスへの移行 - Qiita

  • ドメイン駆動設計の比類なきパワーでRailsレガシーコードなど大爆殺したるわあああ！！！ - Qiita

    この記事は クラウドワークスアドベントカレンダー2019 12日目の記事です。 概要 こんにちは、怒り駆動リファクタリングを生業としている @MinoDriven です。 弊社リファクタリング専門チーム「バグハンター」で現在実施中のリファクタリング設計について紹介致します。 ドメイン駆動設計 を用い、Railsレガシーコードに対しViewとControllerを ActiveRecord非依存 に変更する設計です。 状況 弊社ブログの過去エントリにあるように、弊社サービスcrowdworks.jpはサービスインから8年経過し、 30万行 を超えるモノリシックRailsアプリになっています。 開発生産性が低下してきています 。 生産性低下の課題を解決しようにも、大規模な上に複雑かつ密結合な構造になっており、 マイクロサービスへの移行も、リプレイスも困難な制約 があります。 そこで半年前にリフ

    ドメイン駆動設計の比類なきパワーでRailsレガシーコードなど大爆殺したるわあああ！！！ - Qiita

  • DDDの頻出用語をなんとなく理解する - Qiita

    はじめに DDDの勉強を始めてみたものの初見の用語がバンバン出てきて心が折れそうになったので、雑にまとめてみました。 「雑だけどなんとなく分かる」を優先しているので一部正確ではない表現があるかもですがご容赦ください。 （航空監視システムの話がちょくちょく出ているのはDDD Quicklyの例でよく使われていたためです。） 全体的な話 ドメイン システム化しようとしている現実世界の万物です。 例えば航空監視システムを作ろうとしているなら、航空監視に必要な人・モノ・情報・業務・etc...です。 当然これら全てをシステムに落とし込むことはできません。 ドメインモデル システムに落とし込めるよう、ドメインをシンプルに捉え直した（＝モデリングした）ものです。 ドメインに詳しい人（その業務の担当者等）とエンジニアで共同で作ります。 モデリングの手法についてはググってみたらたくさん出てくるので調べてみ

    DDDの頻出用語をなんとなく理解する - Qiita

  • Software Architecture - DDD と アーキテクチャ にまつわるエトセトラ - Qiita

    要約 / inb4 tl;dr DDD（ドメイン駆動設計）について調べ始めたら、解説記事でお腹いっぱいになった。 更に、一緒に語られるアーキテクチャも整理したい欲が出てきた。 Layered Architecture Layered Architecture with DIP (Dependency inversion principle) Hexagonal Architecture Onion Architecture Clean Architecture こういった経緯で、元になった書籍や記事をまとめてみた。 ちょっとしたまとめも書いた はじめに 『ドメイン駆動設計入門 ボトムアップでわかる！ドメイン駆動設計の基本』 を読んで DDD入門をしてみて、ボトムアップで作り上げるときの アーキテクチャ に興味が湧き、今後、調べていくに当たって最初に見るべきであろう情報をまとめてみました。

    Software Architecture - DDD と アーキテクチャ にまつわるエトセトラ - Qiita

  • Let's Encrypt に重大なバグが発覚。該当サイトは2020/3/4 までに対応が必須 - Qiita

    Let's Encrypt にバグが発見されました。利用ドメイン全体の 2.6% のサイトに影響があるとの事です 有効な証明書の 2.6% に影響があるとの事です。影響があるサイトは 2020/3/4 までに対応が必要です。すでに期限は過ぎています。該当サイトには個別にメールが届きますが、メールが届かない場合もあるとの事なので注意して下さい。 この記事では問題の概要と該当するかどうかの確認方法、および対応方法について記載しています。 記事の修正を行いました（2020/3/6 追記） この記事は筆者の予想をはるかに超えて多くの方に読んで頂きました。ありがとうございます。改めて読み返してみると不完全な部分も多かったため、以下の修正を行いました。 2.6% の意味が不正確だったので修正 バグの概要と、その影響について以下の項に追記 問題の概要 どんな影響があるのか？ 確認方法の詳細、補足説明、注

    Let's Encrypt に重大なバグが発覚。該当サイトは2020/3/4 までに対応が必須 - Qiita

  • Object-Oriented Conference参加メモ - Qiita

    Object-Oriented Conference概要 ※イベント及びセッションの概要は公式HPから引用しました。 2020.02.16 SUN 10:00 - 17:00 お茶の水女子大学 #ooc_2020 Object-Oriented Conference はオブジェクト指向をテーマに、あれこれ共有したり、セッションを聴講することで、みなさんの知見を深めるためのイベントです。 オブジェクト指向といっても、分析設計から、現場で活かすためのプラクティスなど様々なテーマがあります。セッションやラウンドテーブルなどを通じて、参加者の皆様が新たな発見を持ち帰っていただけるようなイベントを目指しています。 オブジェクト指向についてまったく知らない方やオブジェクト指向を完全に理解した方、そして普段オブジェクト指向以外のパラダイムを利用している方もお気軽にご参加ください！ 開会の挨拶 オブジェク

    Object-Oriented Conference参加メモ - Qiita

  • Google Maps APIで50万以上使っていた話 - Qiita

    この記事は Wano Group Advent Calendar 2019 の7目の記事となります。 アドベントカレンダーに「なにか」書くといって7日を予約していたんですが、特にネタを考えてなかったら、前日にネタが降ってきたという話です。 ※後日談を追加しました(2019/12/15) 始まりは経理担当者のSさんの指摘 ちょうど昨日(12/06)のことです。経理担当者のSさんに「Google Cloud Service から38,653円がクレジットカードの明細にあるのですが、証憑がないんですが…」と相談を受けました。月初は会社に対する請求の確認作業があり、請求書がない引き落としとかは問題になりますので、たまに確認されることがあります。 新しくサービスを開始する際に、AWSやGCPとか有料サービスのアカウントを新しく作る必要があったりすると、そんなことが起きたりします。要は経理担当にメール

    Google Maps APIで50万以上使っていた話 - Qiita

  • 127.0.0.1に名前解決するループバックドメインloopback.jpを作った - Qiita

    osxでプロダクションに限りなく近い開発環境を準備するのコメントでlvh.meのことを知った。 lvh.meというループバックドメイン localhost以外のドメインやサブドメインでのテストをしたいとき、/etc/hostsに書いたりローカルにDNSサーバーを立てる方法があるが、普通のドメインを127.0.0.1に解決させてしまえば確かにお手軽だ。 仕組みも簡単なので自分用に作ることにした。 適当なドメインを用意し、トップレベルドメインloopback.jp.とワイルドカード*.loopback.jp.のAレコードに127.0.0.1を指定する。 以下のいずれも127.0.0.1に名前解決される。 loopback.jp www.loopback.jp sub.domain.loopback.jp 例えばサブドメインで言語を設定するサイトを作っているとする。 うんお手軽！ 仕様 loop

    127.0.0.1に名前解決するループバックドメインloopback.jpを作った - Qiita

  • DNS over HTTPSの必要性について - Qiita

    なぜ今までのDNSでは問題があるのか インターネット上の通信の多くは、ブラウザを利用したウェブによるものです。 セキュリティ向上のため、GoogleやFireFoxといった大手ブラウザベンダーが平文通信であるHTTPから暗号通信であるHTTPSへの移行を推奨し、盗聴・改竄・なりすましといった問題を解決することが出来ます。 しかしながら、そのHTTPS通信をする前のDNSによるドメイン解決は暗号化されておらず盗聴でアクセスするホスト名を把握される、なりすましで偽の応答を返されるといった可能性があります。 それを防ぐための方法の1つが、DNS over HTTPSです。 DNS over HTTPSとは 今までDNSサーバ（フルリゾルバ）の（主に）UDPポート53番に対して行われていたDNSによる名前解決を、TCPポート443番に対するHTTPS(HTTP/2 over TLS)通信上で行うプ

    DNS over HTTPSの必要性について - Qiita

  • Reduxにドメイン層を導入する - Qiita

    【2018/6/18更新】immutable.js を利用せずに、当エントリー同等以上の開発が可能な、FP・型推論の強いモジュールを公開しました。https://qiita.com/Takepepe/items/a79e767b38981c910c3f ドメインモデルの需要 フロントエンドフレームワークでプロダクトを作り込んでいくと、ビジネスロジックが view に介入しすぎてしまうことが少なからずあります。下記の様なビジネスロジックが散在しているコードに、スケール耐性があるとは思えません。リリース当時は単純だったものが、複雑に変化していくケースは往々にしてあります。 function TodoItems (props) { const { todos, updateTodo, deleteTodo } = props const items = todos.map(item , i) =

    Reduxにドメイン層を導入する - Qiita

  • 実装 - Hexagonal Redux - - Qiita

    Reduxのヘキサゴナルアーキテクチャ Reduxの様なイベント駆動アーキテクチャでDDDの恩恵を受けるため、ヘキサゴナルアーキテクチャを採用するモデリングの考察です。疎結合なドメインモデル同士は、時に外部ドメインで扱う横断的関心事を参照する必要が出てきます。 Redux は SingleStore のため、全部入りのエンタープライズモデルと捉えられがちですが、それを構成する Reducer と対の Model が、マルチドメインを構成する単体のドメインモデルだと捉えています。先日投稿したモジュールの構成で、ヘキサゴナルアーキテクチャを採用する準備は出来ています。用語のマッピングは以下の通りです。 DomainModel = immutable.Record DomainEvent = ReduxAction Port(in) = ReduxReducer Port(out) = Redu

    実装 - Hexagonal Redux - - Qiita

  • UXD and DDD (UX デザインとドメイン駆動設計) - Qiita

    はじめに NewsPicks のソフトウェアエンジニアの三浦です。NewsPicks アカデミア というプロダクトの開発チームリーダーをやっています。NewsPicks Advent Calendar 2018 の12日目を担当します。 今回は、ソフトウェアエンジニア視点でのプロダクトづくりについて、 UX デザイン(以下 UXD)とドメイン駆動設計（以下DDD）を中心に書いてみようと思います。 なぜ UXD と DDD を同時に論じようと思ったのか 結論から先に書くと UXD と DDD は親和性が高いのではないか？と考えたからです。 伝統的なソフトウェア開発のプロセスを挙げると、 要件定義 基本設計 詳細設計 実装 テスト リリース のような構成になると思います。 しかしこのプロセスで開発したソフトウェアはユーザにとって魅力的なものになるでしょうか？ 昔よくあった、やたら入力項目が多か

    UXD and DDD (UX デザインとドメイン駆動設計) - Qiita

  • ドメインオブジェクトを中心としたClean Architecture のためのレイヤー構成 - Qiita

    ドメインオブジェクトを中心としたClean Architectureは、どういうレイヤー構成にするとよいか、簡単にまとめてみた。 イメージ たぶん、こんな感じになるはず。通常は円状に表現するが、わかりにくいので層状に書いてみた。 赤い部分の層は、直接依存の方向が上から下です。グレー部分の層は、契約だけが定義された独立した層で、ユースケース層やインターフェイス層から依存できるものとします。 インターフェイス（アダプタ）層 内外とのデータ形式の変換が主な役割 コントローラ、プレゼンター（内部から外部へデータ形式を変換する責務）,ゲートウェイ(外部と通信する責務。DBやRPC) ユースケース層 アプリーケーション層ともいう アプリケーション固有のビジネスルールをカプセル化する ドメイン層 Clean Architecture本では、中心にはエンティティとだけ書かれているが、DDDでは中心はドメイ

    ドメインオブジェクトを中心としたClean Architecture のためのレイヤー構成 - Qiita

  • 役割駆動設計で巨大クラスを爆殺する - Qiita

    大量のメソッドを保有し、数千、数万行単位にぶくぶく膨れ上がった巨大クラス。別名「神クラス」とも「大きな泥団子」とも呼ばれる、長大で複雑で密結合で極めて変更が困難なアイツ。 そんな巨大クラスの退治に有効な、ドメイン駆動設計を基本思想とする「役割駆動設計」を紹介致します。 解決したい課題、狙う効果 数千、数万行単位の巨大クラスの登場を抑止する。 小さくシンプルな構造に落とし込み、堅牢で変更容易性の高い設計へ昇華させる。 例１：筆者をモデリング 分かりやすくなるよう、まず私を例にモデリングしてみます。私は以下のような特徴があります。 IT企業の従業員 家族がいる(妻, 子供) 趣味でゲーム制作している ダメな設計 何も考えずに人クラスとして設計すると、よく以下のような構造になりがちです。 従業員として仕事をする、父親として家族サービスする、趣味としてゲーム制作する、それぞれのメソッドが備わってい

    役割駆動設計で巨大クラスを爆殺する - Qiita

  • ドメインオブジェクトの責務について - Qiita

    設計するとき、「このオブジェクトの責務は何だろうか？」とか「この責務に名前をつけるなら何か？」とか、責務について考えることがよくあります。そもそもその責務とは何か、という根源的な疑問について再確認すると共に、ドメイン駆動設計の観点からドメインオブジェクトの責務についても考えてみたいと思います。 責務とは 困ったときの古典引用。もう絶版になった、オブジェクトデザインという、書籍を紐解いてみましょう。DDDからの引用が多い書籍で、DDDの設計スタイルは、この書籍で紹介する「責務駆動設計(responsibillity-driven design)」の原則に従うことが大きいとされています。 この書籍によると、「責務」には以下が含まれるそうです。 「4.1 責務とは何か」 オブジェクトが行う動作 オブジェクトが持つ知識 オブジェクトが他に影響を与える主要な判断 これらの言葉を身近な言葉で置き換える

    ドメインオブジェクトの責務について - Qiita

  • 「実践ドメイン駆動設計」を読んだので、実際にDDDで設計して作ってみた！ - Qiita

    こんにちは、クラウドワークスの新規事業のエンジニアとして仕事をしている高梨です！ 最近、「実践ドメイン駆動設計」という本を読みました！ 500ページ近くもある技術書で、なかなか量は多かったのですが、DDDがどんなものなのか一通り大枠を掴めた気がします。 ただ読み終わった後にこんな疑念や不安をいだきました。 「たしかにかなり面白そうだけど、実際にやるとどれだけ工数かかるんだろう...？」 「設計の話は全然出てこなかったけど、DDDで作るとなるといったい何から始めればいいんだ？」 「戦術についての知識はついたけど、実際に書こうとしたらできなそうだな...」 そこで、そういった疑念や不安を解決するために、実際にDDDでサンプルプロダクトを作ってみようと思ったわけです。 実際に作ってみるのが、結局一番理解が進みますしね。 今回は、そのプロダクトがリリースされるまでの過程や感想を、作成した設計書やソ

    「実践ドメイン駆動設計」を読んだので、実際にDDDで設計して作ってみた！ - Qiita

  • 転移学習：機械学習の次のフロンティアへの招待 - Qiita

    機械学習を実務で使う場合、「ではお客様、ラベルデータを・・・」と申し出て色よい返事が返ってくることはあまりありません。また、例えば自動運転車を作るときに、データが足りないからその辺流してくるか、お前ボンネットに立ってデータとってな、とするのは大変です。 NICO Touches the Walls 『まっすぐなうた』 より そこで必要になってくるのが転移学習です。 転移学習とは、端的に言えばある領域で学習させたモデルを、別の領域に適応させる技術です。具体的には、広くデータが手に入る領域で学習させたモデルを少ないデータしかない領域に適応させたり、シミュレーター環境で学習させたモデルを現実に適応させたりする技術です。これにより、少ないデータしかない領域でのモデル構築や、ボンネットに立つという危険を侵さずにモデルを構築することができるというわけです。 この転移学習の可能性は、NIPS 2016

    転移学習：機械学習の次のフロンティアへの招待 - Qiita

  • ドメイン駆動設計における２つの『不変』 - Qiita

    この記事は ドメイン駆動設計 advent calendar 11日目 の記事です。 日本語版だとわかりずらい「不変(不変条件)」 エヴァンスのドメイン本では、頻繁に「不変(不変条件)」という言葉が出てきます。Kindleで検索してみたところ、83件でした。 分類してみると、主に2箇所でよく使われています。 １つは「ValueObject(値オブジェクト)」の項。もう一つは「Aggregate(集約)」の項です。 Factoryでも多く使われていますが、こちらはAggregateの不変条件に関連する内容ですね。 さて、実は「ValueObject」と「Aggregate」で使われている「不変(不変条件)」の意味って全然違う意味なんです。 弊社でドメイン駆動設計の読書会をしているなかで、話題になり目から鱗が出てしまったので紹介しますね。 「ValueObject」と「Aggregate」の項

    ドメイン駆動設計における２つの『不変』 - Qiita

  • エンジニアが記事を書くためのブログやサービスまとめ - Crieit

    エンジニアがアウトプット等の目的のためにIT系、テック系のブログを作ったり、サービス上で記事を書きたい、という場合があると思います。色々と選択肢があると思いますが、どういったものが良いのでしょうか？　僕自身実際に色々と使ったことがあるので、考察してみました。2020/9時点での考察となります。 特に下記あたりを考察しています。 使い勝手 集客能力 はてなブログ 使い勝手は？ はてなブログは恐らくブログサービスの中ではエンジニアに一番人気のものになると思います。僕も以前使っていました。 markdownで記事が書け、プログラム等のコードもちゃんと書けるので、技術系の記事を書くのには非常に適していると思います。デザインもカスタマイズ可能で非常に使いやすかったです。 有料ですが独自ドメインも使えますし、現在はSSLにも対応しています。 集客能力は？ 特別なにか大きな集客能力は無いと思います。基本

    エンジニアが記事を書くためのブログやサービスまとめ - Crieit
  • 1

お知らせ

もっと読む

公式Twitter

  • @HatenaBookmark

    リリース、障害情報などのサービスのお知らせ

  • @hatebu

    最新の人気エントリーの配信

はてなブックマーク

公式Twitter

はてなのサービス

  • App Storeからダウンロード
  • Google Playで手に入れよう
Copyright © 2005-2024 Hatena. All Rights Reserved.