ChatWork Advent Calendar 2017の10日目の記事です。 こんにちは。かとじゅん([Twitter:@j5ik2o]) です。 何を書こうかと悩んだのですが、社内で意見を聞いたところ、やはりDDD関連がよいとなりました。 Scalaコードでわかった気になるDDD この記事も、もう四年前ですっかり古くなりました。最近どういう観点で実践しているかまとめてみます。(DDD初級者という方は、まず上の記事を読むことをお勧めします) DDDを実践するにあたっての個人的な問題点は2つあります。ひとつは、「いきなりドメインモデルを作ることができない」という問題。もうひとつは、ドメインモデルを作り上げても実装コードに役に立つ振る舞いが思いつかず、いわゆる「ドメインモデル貧血症*1」になりやすいという問題です。このような問題は、僕がコミュニティで関わった多くのエンジニアから耳にします。

この記事は アイスタイル Advent Calendar 2023 12日目の記事です。 はじめに みなさんこんにちは。 アイスタイルのバックエンドサービスを担当しているkuriyamayです。 アドベントカレンダーへの参加もお馴染みとなりました。 過去の記事はこちらです。 2020年 kubernetes(k8s)を構築してデプロイやスケールで遊んでみた 2021年 Java SE 11(Java Silver)を受験した話 2022年 curry化と部分適用をJavaで curry化と部分適用をJavaで ~命名編~ 2023年はCQRSとEventSourcingについて書いていこうと思います。 CQRS / EventSourcing CQRSとは CQRS（Command Query Responsibility Segregation）は2010年にGreg Youngさんによ

チームで仕事するとき、みんなもう少し自分の存在、自分のリアクションがチームに与える影響を自覚した方がいい。 例えばミーティングでブレストしているとき、議論が前に進むのは、あるときふと場に出されたアイデアに対して、誰かが"それいいですね"って言った瞬間である。アイデアを出したとき、その人にはふつう、確信なんてほとんどない。僕なんか自分の意見に自信なんかなくて(大体みんなそうなのだ)、言ってみて、まわりの反応を見て、あ、なんか良さそうだ…と思ったときにやっと前に進むことができる。みんな、自信なんてないのだ。だからアイデアは、場に出されたときはまだ、波際の砂のお城のようにやわらかである。 しかし、あるアイデアに対して、それいいね、と声をもらったとき。いい顔が見えたとき。姿勢が前のめりになってくるとき。そのときとあるアイデアは、はじめて光るのだ、形になる可能性を見せるのだ。 * 逆に言えば、議論に

本記事は READYFOR 株式会社の READYFOR Advent Calendar 2023 の [15日目] です。 ※ 本記事の内容は所属会社の公式発表・見解を示すものではありません。 ■ 「言葉集め会」とは？ 弊社 READYFOR では2年ほど前より DDD に関する取り組みを行っています。 「言葉集め会」とは、そんな弊社にて実施した コンテキストマップの作成や精度向上 を主目的とした 『ドメインエキスパートの皆さんを招待し、仕事で使う「言葉」とその関係性を改めて見出してみる』イベント です。 同僚の方が前職の体験を元に考案したもので、準備を除き全体でおよそ4時間という少し長丁場のプラクティスとなります。 その経験について本日はお話をさせて頂きます。 ■「言葉集め会」で期待できること 「言葉集め会」を実施することで、以下の効果を期待することができます。 エンジニア目線 自社の

noteではかなりざっくりした話を書く。 今回は「開発はどこから始めればよいか」に対するアプローチについて。 開発プロセスの開始点についての質問は一般的であり、特に要件が不明確な場合には、次のような手法を採用することが多い。 ツールの選択は多岐にわたるが、必要に応じて適切なものを選ぶことが重要である。 イベントストーミング ユーザーストーリーマッピング リレーションシップ駆動要件分析(RDRA) ドメインモデルの設計と実装に入る前に、システムの全体像を把握した上で、少なくともユーザーストーリと概念モデルを定義しておくことが重要である。 テスト駆動開発（TDD）のアプローチでは、ユーザーストーリーを基に最初にテストを記述する。例えば、「オークションに最高額で入札する」というユーザーストーリーがある場合、以下のようにメソッド呼び出し部分を想起しながらテストを作る。 auction, err =

記事のポイント 多くの組織が心理的安全性を「思いやり」や「いい人であること」と誤解しており、これがビジネスに悪影響を及ぼしている。 従業員が報復を恐れずに問題を指摘できる環境を作ること。これにより最高の業績とパフォーマン […] 記事のポイント 多くの組織が心理的安全性を「思いやり」や「いい人であること」と誤解しており、これがビジネスに悪影響を及ぼしている。 従業員が報復を恐れずに問題を指摘できる環境を作ること。これにより最高の業績とパフォーマンスが生まれる。 心理的安全性の概念を長年研究してきたエイミー・エドモンソン教授は、心理的安全性が「弱み」ではなく「武器」になると強調し、正しい理解と適用が必要であると説く。 雇用主は従業員の心理的安全性（psychological safety）を十分に理解できていない。そしてそれはビジネス上、極めて良くないことであると、専門家は警鐘を鳴らしている

本エントリはカケハシ Part 2 Advent Calendar 2023の13日目の記事です。 （Part 1もおもしろい記事がいっぱいあるので、ぜひご覧ください。） はじめに こんにちは。カケハシでソフトウェアエンジニアをしている平松です。 今年、新規プロダクト立ち上げの機会があり、その際に行ったフロントエンドの技術選定について紹介したいと思います。 フロントエンドの領域は選択肢が豊富で、変化のスピードも速いため、プロダクトの要件に適した技術を選ぶことはひとつの挑戦です。 実際、フロントエンド技術選定のヒント 【令和五年度版】のアドベントカレンダー記事を読んで、その難しさを改めて感じました。 今回の新規プロダクトは、ユーザがログインして利用するtoBの業務システムです。 私はカケハシでは2度目の新規プロダクト立ち上げですが、前回の経験を活かしつつ、新しいアプローチにも挑戦しています。

大変多く読んでいただいた「プログラミングというより物事が出来る思考法」というポストや、世界一流エンジニアの思考法の書籍で紹介した内容がある。 私の職場でも、ものすごく出来る人が「実践」しているところを何回も目撃しているので「実践編」として皆さんにシェアしようと思って今回のポストを書いてみた。 タイトルにもある通り、私はエンジニアだが、ビジネス書である書籍と書かれた多くの思考法と同じく、あまりエンジニアリングというものに関係ない要素であると感じている。 上記のポストや書籍でシェアした内容を端的に言うと「理解には時間がかかるがかける価値が十分あり、それによって自分が物事をコントロールしている感覚を身につけることが出来る」という自分の小さな発見だ。私がこのことを最初に発見したのは、新卒の出来る人々との出来事がきっかけだが、今回その小さな自分なりの発見を後押しするような出来事がいくつかあった。それ

Scala 3におけるデータ指向プログラミング（以下DOP）について深掘りする。久々にScalaの話題を取り上げるが、これはScala Advent Calendar 2023の14日目の内容でもある。 早速だけど、DOPの基本原則は意外とシンプルだ。 コード（動作）をデータから切り離す データを汎用的なデータ構造で表現する データをイミュータブル（不変）として扱う データスキーマをデータ表現から切り離す イミュータブルなデータは採用することは多いと思うが、これをそのまま実践している人はどのくらいいるだろうか。Scalaではクラス中心の関数型プログラミングが主流だと思うし、私もそうしている。 DOPの詳細は下記の本(以下DOP本)を参照してほしい。 データ指向プログラミング 作者:Yehonathan Sharvit翔泳社Amazon ちなみに留意すべき点がある。DOP本とJavaのPro

この記事は 株式会社ログラス Productチーム Advent Calendar 2023 13日目の記事です。 はじめに 〇〇を削除できるかどうかのビジネス処理、皆さんはどう実装していますか？ 同僚の話題になった記事でも削除の認可処理をどこに記述すべきか？は難しいと説明されています。今回はお題は認可っぽいもので書きますが広範に「削除ができるかどうか？」のビジネスロジックをドメイン層にどう閉じ込めるかの便利な実装パターンを紹介します。 削除処理のビジネスロジックの取り扱いは難しい 削除処理のビジネスロジックの実装はシンプルだけど更新処理や作成処理と比べて意外と難しいです。 それはなぜかというとドメインオブジェクト内の実装に削除処理を書くことができないからです。 例えば権限に管理者と一般ユーザーの二つの権限があるとします。

はじめに 最近プロジェクトマネジメント関連の仕事をする機会が増え、要件定義や設計関連の業務もするようになったので、私の経験を基に要件定義の具体的なプロセスや考え方について、まとめていきます。 本記事について Findy様の「要件定義 先達に学ぶ今日から使える実践テクニック Lunch LT」で登壇した内容を元に作成しています。 この記事の対象者 要件定義の基本や思考プロセスを学びたい人 エンジニアからプロジェクトマネジメントをやりたい人 ビジネスサイドとエンジニアサイドのコミニュケーション能力を向上させたい人 具体的な事例を通して要件定義を学びたい人 前提 紹介する内容はあくまで一例であり、プロジェクトやチームの状況に応じて調整が必要 あくまで自分(駆け出しPM)の経験に基づいた内容を言語化しています プロジェクト規模は10名〜20名のWebアプリ開発を想定しています システム開発の全体像

※当アカウントは特殊な訓練を受けています、良い子はマネしないでね！ ※当地ホンジュラスは。10万人あたりの殺人件数が世界ランキング1〜4位をここ10年間彷徨っており殺人事件の90％以上が捕まらない国です、判断ミスったら射殺されます、以下の記事はあくまで酒のつまみとしてお楽しみください 始まりこの旅程のルート この日はエルサルバドルの首都サンサルバドルからホンジュラスの北部にあるコパン・ルイナスという遺跡観光都市に向けて移動していた。早起きして7時には出発しエルサルバドルを出国してホンジュラスへと入国したのは午前11時前のことである。 いいペースで動けていたがこの時通過したエル・ポイという街からコパンへはオコテペケ、ラ・エントラーダという街を経由しないと辿り着かない。乗り換えが多い区間であった。 国境からオコテペケで乗り換えラ・エントラーダへと向かう。この路線は一発で行けるはずであった。が、

はじめに 色々あって，ここ数年間は「エンジニアになりたい学生」と多く触れ，そして励ましてきました。新卒採用やインターンシップ採用の選考に関わっていたこともあります。悲しいことに学生のみなさんはさまざまな情報に踊らされ，焦らされ，煽られてしまっています。特にTwitterやブログでは，なんとか生き残っていた人たちの生存バイアスばかりが目立ちます。人事は会社ごとに言ってくることが違うし，いったいなにを信じればいいのかわからなくなっていることでしょう。そんな学生のみなさんの不安を少しでも払拭できればいいと思って，ひとりひとりとお話して励ましてきたことを今回こうして文章にまとめています この文章がエンジニアになりたいけれど，なんとなく不安を抱えている学生の方々の助けになればとてもうれしいです。もちろんこの文章は私が所属する企業を代表する意見ではありませんし，あくまで私が考える「こういうふうに考える

本記事は株式会社ログラス Productチーム Advent Calendar 2023の 10日目の記事です。 みなさんこんにちは！ログラスでプロダクト責任者をしている斉藤です。 今回は「丁稚奉公から始まる異業種探索」と称して #pmconf2023 で登壇をしてきたのでその内容を10分でキャッチアップいただけるようnoteにしてみようと思います。 3行でまとめると新規事業開発や新規マーケット展開には深い顧客理解が必要 「丁稚奉公」を実施すると、顧客からの信頼と将来の確信を得られる。 みんなも丁稚奉公してみようぜ！ きっかけ： もっと多くの経営企画のみなさんのお役に立ちたい！Loglassは経営企画の皆様により正確かつ迅速にデータを可視化する経営管理クラウドです。 要は経営にまつわるいろんな情報をExcelで頑張って統合している企業さんがLoglassを入れれば、情報の統合が楽になり、ぱ

アーキテクチャ刷新にどのように立ち向かったかのお話です。 何を予測し 何を準備し 何を失敗したか そんなお話です。 【プロポーザル】 ある特定の課題を解決するために、未知の技術や方法を採用する必要に迫られる状況は、技術者のキャリアの中で度々出くわすものです。 私も最近、そのような挑戦的な状況に直面しました。 このセッションでは、新しいアーキテクチャや技術基盤を導入する過程で私が行った取り組みや準備、そしてそれらの採用によってもたらされた実際の結果や変化についてお話します。 採用の背景から選択の過程、そして実際の結果までの道のりを通して、未知の技術やアーキテクチャの採用に関する有益な知見や学びを共有いたします。 こちらはGMO Deceloper Day 2023 でお話しました。 詳細は以下をどうぞ。 https://developers.gmo.jp/developersday/?ses

AndroidのためのJava/Kotlinはスコープ外とします まず断っておくと、俺はScalaが好きだ。 自分が作ったScalaプロダクトは二個現存している。うち一つはまだまだ自分が開発している。というか今は会社を作って1人でプロダクトを作っている身なのだが、それもScala3+ZIO2でゴリゴリ書いている。 でも残念、もうScalaというかJVM言語がオススメできません。TypeScriptかGoかRustをオススメします。 どういうこと？まずこの記事を見ていただくのが一番分かりやすい。 https://aws.amazon.com/jp/builders-flash/202310/java-serverless-saas-backend/?awsf.filter-name=*all 素晴らしいエントリーだ。読みに行かないせっかちな方のために概要を紹介する JavaプロダクトをAWS

ウォンテッドリー株式会社の社内イベント "Tech Lunch" で話した発表です。 プログラムには大小さまざまな粒度の「状態」が存在します。 状態の設計を工夫することで、コーナーケースの発生を抑止し、ユーザー体験を最適化することができます。 本発表では、私が普段どのように「状態」について考えているか、言語や環境を問わずできるだけ普遍的に使える形での言語化を試みます。本発表を通じて、「状態」をなんとなくではなく合理的に設計するためのヒントを提供します。 GoogleスライドのURL: https://docs.google.com/presentation/d/1PNzz69UV05HlKPuWGlooemnPslLbLKsyLwl3R4U_XqE/edit

すべてのフェーズでミスが重なった ―全銀ネットとNTTデータ⁠⁠、全銀システム通信障害の詳細を説明 全国銀行資金決済ネットワーク（以下、全銀ネット）とNTTデータは12月1日、2023年10月10日～11日にかけて全国銀行データ通信システム（以下、全銀システム）で発生した通信障害に関する報道関係者向けの説明会を開催しました。本件についてはNTTデータが11月6日に行った途中経過報告の内容をもとにレポートしましたが、今回、全銀ネットとNTTデータが揃って会見を行ったことで、より詳細な障害の原因が判明したので、あらためてその内容を検証してみたいと思います。 説明会の登壇者。左から、全銀ネット 企画部長 千葉雄一氏、事務局長兼業務部長 小林健一氏、理事長 辻松雄氏、NTTデータ 代表取締役社長佐々木 裕氏、取締役副社長執行役員 鈴木正範氏 なお、全銀ネットとNTTデータは、今回の障害に関して金融

TOPインタビューエンジニアが好きすぎてDevRelになった。タイミーかわまた氏に聞く「開発者が思う存分価値発揮できる組織」のつくりかた 株式会社タイミー　プロダクト本部DevEnableG　DevRel かわまた（河又涼） 新卒で株式会社サトーに入社、営業としてラベルプリンターやハンディターミナルを活用したソリューション提案を担当。その後株式会社groovesにて、Forkwell事業部のリードセールスとして活動。セールスと海外事業の兼任を経て、Forkwell DevRel Teamに異動、エンジニア向けのイベント企画とDevRel Specialistとして活動。2023年5月、株式会社タイミーに入社、DevRelとして技術的な認知活動を担う。 エンジニア採用に力を入れる企業が増えてきた昨今、採用を見据えた技術広報的な意味合いを持ちつつ、自社のエンジニア組織を盛り上げる役割を担う「D