この記事はドメイン駆動設計 #2 Advent Calendar 2018の16日目の記事です。 DDD(ドメイン駆動設計)とは何なのか そもそもDDDってなんなの？ということをちょくちょく聞かれます。 一言で言うと、「開発手法の一種です」ですが、それだと「ふ〜ん」で終わってしまうので、もう少し興味を持ってもらえる回答を考えます。 まず、開発してて何に困るのかがわからないと思うので、そこから説明をします。 非エンジニア向けの説明 開発手法にも色々あり、行き当たりばったりに作ると以下のような問題に突き当たる、ということがよくあります。 実際の業務をきちんと理解しないで作ったら、 リリースしてもあんまり使われなかったり不評なものができる きちんと整理されてないプログラムを書いたら、 あとから修正するのがどんどん大変になる DDDは、このの2個とも解決しよう、ということで生まれた設計・開発手法な

ドメイン駆動設計で実装を始めるのに一番とっつきやすいアーキテクチャは何か ドメイン駆動 + オニオンアーキテクチャ概略 以前こちらの記事でアプリケーションアーキテクチャについて書きました。 こちらの記事では比較的ネタ元に忠実な解説をしたのですが、実際これに基づいて人にレイヤの説明をした際、依存性の逆転部分や円形で表現する部分がなかなか伝わりにくいことがありました。 そんな中で、所属プロダクトで新卒含めて大規模なリニューアル案件でDDDを採用することになり、新卒にも伝わるように説明をする必要性が生じました。 結果、新卒にも伝わり、運用が割と回る説明が見つかったのでご紹介したいと思います。 アプリケーションアーキテクチャ全体図 とにかく、何か説明する際はこの図を常に傍に置き、一方通行の依存性を徹底したい、という話をしています。 何かについて議論をする際は、 「それはどの層の責務なの？」 という

こんにちは。HRMOS採用管理事業部のプロダクト開発部でアプリケーションエンジニアをしております、新卒2年目の澤なつみと申します。 普段はScalaで開発をしているのですが、この度先輩とタッグを組み、ログ基盤構築という新しい挑戦をしました。 今回の記事では、ログ基盤の本番運用を目指して試行錯誤した約三ヶ月間の旅の記録をお届けしようと思います。 コトの発端 ~ログってどこからきたの？~ HRMOSの開発者は日々、データ可視化ツールであるkibanaを使ってエラーログの監視をしています。それを配属されてからずっと、当たり前のように利用していた私はふと疑問に思いました。「このアプリケーションログってどこからきたの？」 と。 その時私は、 ログは鳥が運んでいる ことを知りました。（笑）HRMOSではコンテナ型の仮想環境であるDockerを利用しているのですが、Dockerコンテナから出力されたログ

ドメイン駆動設計の定義についてEric Evansはなんと言っているのか の記事の中で、EricEvansのドメイン駆動の定義を引用して以下のように和訳しました。 ドメインの中核となる複雑さと機会に焦点を当てる ドメイン専門家とソフトウェア専門家のコラボレーションでモデルを探求する 明示的にそれらのモデルを表現するソフトウェアを書く 境界付けられたコンテキストの中のユビキタス言語で話す この中で、重要なポイントが明示されていませんでした。 定義にある4点のようなことを、なぜやる必要があるのか？ ということです。 つまり、ドメイン駆動設計は、一体何を解決しようとしているのでしょうか？ ドメイン駆動設計は何を解決しようとしているのか DDDはソフトウェア開発手法の一つです。 なのでまず、ソフトウェア開発の目的について考えてみましょう。 人々はなぜ、ソフトウェアを開発するのでしょうか？ それは、

キャリトレ事業部の松岡(@little_hand_s)です。 キャリトレチームでスクラム開発を導入し、議論の機会が増えたため、議論自体の効率化必要性に突き当たりました。 そこで、会議設計やファシリテーションの書籍を何冊か読み、実際に現場で実践してみたころ、 議論が必要な仕事であれば幅広く、確実に生産性を向上できるという手応えがありました。 その実践結果から、再現性が高く、すぐ実行できそうなTipsを抜き出してまとめました。 「キャリトレ」は2022年12月21日をもってサービス終了しました。 議論を始める前に、必ず目的とゴールを設定する 議論を行う場合は、以下の2つを必ず設定します。 目的：なぜその会議を行うのか？ ゴール：議論終了時にどういう状態になっていたいか？ これはとにかく基本です。これを守るだけで、生産性が大幅に上がるので、まずはこれを徹底しましょう。 対象は主に会議のような場で

皆さん、初めまして。 2017年新卒入社の牧野美咲(@T5uku5hi)と申します。 キャリトレ事業部のサーバーサイドエンジニアです。 今回は、先日開催したRustの勉強会についてお話したいと思います。 なぜRustの勉強会？ 私は趣味でRustの勉強をしています。 きっかけはこちらのスライドをご覧ください。 Rustのお陰で、普段業務で使っているJavaへの理解が深まった訳ですが、 せっかくだからRustを業務で使ってみたい でも、Rustの使い所や提案の仕方がわからない という状況でした。 わからないから知りたい！ そうだ、Rustを実際に業務で使っている人に教えてもらおう！ 知的好奇心の塊である私は、勉強会を開くことを決意したのでした。 話題の方々に直撃お声がけ タイムリーなことに、Rustユーザーの集うSlackチャンネルで、 「どの日本の会社がRustを使っていますか？」 という

株式会社ビズリーチで、SREエンジニアとして勤務しているmassです。2017年4月に入社してから、HRMOSというサービスのAWSのインフラを管理したり、アーキテクチャの設計・構築をしたりしています。 今回は、入社してから半年経ったらいつのまにかサービスのネットワーク管理者になっていて、そこで発生した問題と、それを解決するのに非常に役立ったCloudMapperというOSSを紹介したいと思います。 発生した問題 私がネットワーク管理者を引き継いだ段階では、ネットワーク構成図が作成されておらず、以下の問題が発生していました。 ロードバランサーを止められない 用途不明のロードバランサーが存在したため、停止を検討した。 しかし、どのリソースから利用されているか見えず、不用意に停止できなかった。 用途不明なEC2インスタンスの調査ができない AWSからメンテナンス通知が来た対象が用途不明なEC2

Dependency Injectionとは Dependency Injectionを日本語でなんと訳しますか？ 大体「依存性の注入」と訳されることが多いですよね。 確かに直訳するとその通りなのですが、実際に行っていることを表していない、非常にミスリーディングな誤訳だと思います。 依存性を注入する、と言われると、まるで新しい依存性が増えるような印象を受けますが、実際はそうではありません。 googleの言語設定を英語にして検索してみると、英語版Wikipediaがトップで出てきて以下のように説明されています。 In software engineering, dependency injection is a technique whereby one object (or static method) supplies the dependencies of another objec

ドメイン駆動設計で実装を始めるのに一番とっつきやすいアーキテクチャは何か - little hands' lab ドメイン駆動 + オニオンアーキテクチャ概略 - little hands' lab これらの記事で書いた通り、私はDDDのレイヤードアーキテクチャを決める際にオニオンアーキテクチャの用語を使っています。これまで色々な人に説明してきて、理解につまづきやすいポイントとしてレイヤの責務の話があったので、そこについて解説します。 一発で伝わりにくい(と思っている)定義 Onion Architecture Is Interesting - DZone Java こちらの記事で書かれている各レイヤの説明 Domain Layer Domain Model layer, where our entities and classes closely related to them e.g.