銀座Rails#26の登壇資料です https://ginza-rails.connpass.com/event/189892/
こんにちは! はじめまして! 2020年7月からPIECE事業部でエンジニアをさせてもらっています。 野澤です。 今回、PIECEというサービスのリニューアルを担当させてもらったのでその時のことについて書きたいと思います! まだ若輩者なので至らない点が多々あると思いますが フルリニューアルってどんな事したんだろう〜? Hajimariのエンジニアはどんな仕事をしてるんだろう〜? って思った人はぜひ読んで見てください! ※ドメイン駆動設計の説明も書いたのですがボリュームが多くなってしまいました… ドメイン駆動設計について概要知りたいという方は是非読んでみてください。 クリーンアーキテクチャの説明やモデリングのやり方などは説明していません。 ご了承ください。 PIECEリファクタリングプロジェクトの概要 PIECEとはどのようなサービスなのか リニューアルの目的 リニューアル施策 ドメイン駆動
設計コース2回めを受けてからだいぶ時間が空いてしまいましが、2回めの内容のまとめと自分なりのメモを取っていたので、噛み砕き反芻するための記事とします。また、3回めを受けた後にまとめているので、3回目の内容を含みながらの考察になります。自分のためにまとめたので、本文はですます調ではなくなってしまって読みにくいと思いますが、ご容赦願います。 設計コースでの参考にする書籍3冊の設計アプローチ 設計コースでは下記3冊の内容に触れながらコースが進められる。 ソフトウェアシステムアーキテクチャ構築の原理(SSA) エリック・エヴァンスのドメイン駆動設計(DDD) オブジェクト指向入門 第2版 原則・コンセプト(OOSC) 第2回の最初の内容では上記3冊の設計アプローチについての説明があった。 ソフトウェアシステムアーキテクチャ構築の原理 特定の設計アプローチを取り扱っているわけではなく、設計における課
RDRAが広まってきているので情報源を充実させたい リチャード 伊真岡です。最近私はRDRAという要件定義手法についてじっくり勉強しています。 RDRAは株式会社バリューソースの神崎善司さん(@zenzengood) が提唱している要件定義の手法です。日本のドメイン駆動設計コミュニティからも注目を集めているようで、ビジネスのルールをきれいにソフトウェアに反映しようとすると、要件定義に目が向くのは自然な流れです。 要件定義手法 RDRA 2.0のハンドブックのサンプル「図書館システム」の実装例です。 RDRAで可視化されたビジネスルール(バリエーション・条件・状態モデル)をビジネスロジックとして実装しています。 ドメイン駆動設計の実装例としても参考にしてください。 https://t.co/UyFscwKMPi#CCSR手法 — 増田 亨. (@masuda220) May 26, 2020
【オンライン】 JJUGナイトセミナー「おうちで!ビール片手にLT大会!」8/26(水) 開催 でLTしてきました。 オンラインLTは難しいですね。 内容 いつも通り目新しいこともない「ふつう」の話です。 元々40分くらいのセッションを煮詰めて5分に押し込みました。 Live(や公開されるであろう動画)で見られた方はめっちゃ端折って話してるのわかるかと思います。 言いたいことは言ったつもりだけど、言えなかったこともスライドには書いてるつもり。 特に大事なとこを挙げるならこの辺かな。 とにかく完成させて公開する。公開を意識するだけで対応する物の優先順位とか、代替パスをどれやっておくかとか。 今できないものをどうしておくか という、現代のプラグラマに必要なスキルが身につけられます。 ループ図のつもり……なんだけど、全部プラスになっちゃってマイナスがでないからそれっぽく見えない。まあいいか。(K
RDRA をやってて思うところ。 RDRAでは多くのダイアグラムが定義されていますが、これらのダイアグラムはきっと成果物(最終的に作るものの中核にあるものをこう呼んでみる)では無いです。多分ハマりどころ。 システムコンテキスト図も業務フロー図もユースケース複合図も、どれもRDRAのエディタとビューアでしかありません。中間成果物、もしくは補足資料的な位置付け。 じゃあ成果物が何かって言うと、各アイコンと関連線。詰まるところ全てのアイコンと関連線を持ったリポジトリそのものが成果物なんだと思います。 ダイアグラムを通してリポジトリを読み書きしている感覚。アイコンを見つけやすい、関連線を引きやすいダイアグラムを使ってアイコンを配置し、アイコン間に関連線を引く。その整合性を確認しやすいダイアグラムを使って、アイコンと関連線を検証する。各ダイアグラムはそのためのものでしか無い。 決して「ダイアグラムを
システム開発の世界において「技術的負債(Technical Debt)」は繰り返し話題になり、しばしば炎上しています。 技術的負債という概念の生みの親は Ward Cunningham (ウォード・カニンガム)です。彼は 1992 年にオブジェクト指向プログラミングの国際カンファレンス OOPSLA '92 の Experience Report でコードの初回リリースを負債に例えました("Shipping first time code is like going into debt")。 Ward Cunningham はソフトウェアの世界に多くの貢献を果たしてきました。Wiki の発明者であり、XP と TDD の父 Kent Beck の師匠のような存在であり、建築の世界の「パタン・ランゲージ」を Kent Beck と共にソフトウェアに輸入した人であり、「アジャイルソフトウェア開
株式会社ビープラウドが主催するIT勉強会「BPStudy」。#151となる今回は、設計の代表格であるオブジェクト指向、モデリング、そして設計にフォーカスをあて、LT大会を開催しました。「ドメイン駆動設計に取り組んだ15年でわかったこと 」に登壇したのは、ドメイン駆動設計に15年取り組み続けている増田亨氏。ビジネスルールと値オブジェクトと型という3つのキーワードを軸に、ドメイン駆動設計をソフトウェア開発に落とし込む方法論について語りました。講演資料はこちら ビジネス活動に起因する複雑さに立ち向かうドメイン駆動設計 増田亨氏(以下、増田):よろしくお願いします。私は2006年ぐらいからドメイン駆動設計に実際に取り組んで、15年ぐらいやっているんですけど、今日はそれを私なりにわかったことというか、けっこう最近振り切ってこうやってますよという内容を、みなさんの参考になればと思って少しお話しします。
ソフトウェア開発の問題点 従来のウォータフォール方式で、フェーズ分けと分業を重視し、手続き的なモジュール構造でソフトウェアを開発するやり方には次の問題があります。 大量のドキュメントの作成に膨大な時間と費用がかかる(工程が多く、必要な人員がふくらむ) フェーズ分けと分業のため、関係者の間の認識合わせが難しい(伝言ゲーム) ちょっとした変更でも、調査・修正・確認に膨大な時間がかかる(変更がやっかいで危険) 一方、アジャイルと呼ばれる開発のやり方は、以下の問題が起きがちです。 ソフトウェアの規模が大きくなると、どこになにが書いてあるか理解ができなくなる 増築・改築の繰り返しが、全体の構造と品質を劣化させる 全体を俯瞰したり構造を確認するための情報がなく、変更の影響がわかりにくい ちょっとした変更でも、調査・修正・確認に膨大な時間がかかる(変更がやっかいで危険) どちらのやり方でも 変更がやっか
ビジネスロジック(ドメインロジック)をどうやってモデリングして、どうやって実装するかの実践例を公開しました。 RDRA 2.0 ハンドブックの図書館システムの実装例 (github) ビジネスロジックのもとになる業務モデルやビジネスルールのモデリングは、 モデルベースの要件定義手法 RDRA2.0 を使っています。 RDRA 2.0 ハンドブック (Kindle Unlimited会員は無償です) 実装技術は、Java/Spring Boot/MyBatis/Thymeleafを使っています。 JIGという設計の可視化ツールを使って、ソースコードからパッケージ関連図やクラスの一覧を自動生成しています。 JIGリポジトリ 利用方法 RDRA 2.0 ハンドブックを入手 リポジトリRDRA 2.0 ハンドブックの図書館システムの実装例をクローン Gradleタスク bootRunを実行(アプリ
ソフトウェアでもっとも重視すべき品質は「発展性」なんだと思う。 機能要求や非機能要求は、時間とともに変化する。その要求の変化に対応してソフトウェアを発展させていける能力、つまり発展性こそがソフトウェアの価値を大きく左右する。 発展性に問題があり変化ができないソフトウェアと、発展性に優れ変化と成長を続けやすいソフトウェアの価値の差ということだ。 発展性の価値 顧客のニーズは変化する。また、市場の競合関係も変化する。そういう事業環境の変化にあわせて、ソフトウェアにも変化を続ける能力が求められている。 また、顧客のニーズや市場環境の変化がゆるやかだとしても、事業活動をすれば組織は経験を通じて学び成長していく。開発チームに限っても、ソフトウェア開発運用の経験を積むことで、開発の考え方とやり方にさまざまな学びと成長がある。そうやって学んだ知識を適切にかつ迅速にソフトウェアに反映できるほど、事業により
Aws Dev Day2021 「ドメイン駆動設計のマイクロサービスへの活用とデベロッパーに求められるスキル」参考資料(松岡パート)
Aws Dev Day2021 「ドメイン駆動設計のマイクロサービスへの活用とデベロッパーに求められるスキル」参考資料(松岡パート)
2020-03-13追記: 「ドメイン駆動設計」のハードルを上げる意図はありません。そもそもそんな特殊技能でもないと思っています。「ドメイン駆動設計が合っているか」を測る材料になるかも?くらいの気持ちで読んでいただけると幸いです。 何度目か知りませんがDDDがまたブームを迎えているようで。DDD難民と言う言葉が出た頃を思うと感慨深いですね。実際難民になったわけではないので肌感覚で知らないのが残念なところですが、これはどうでもいい。 DDD、日本語ではドメイン駆動設計となりますが、DDDを冠していてもドメインが語られることは少ないようです。 数ある書籍もドメインモデリングの話ではなく、ドメインモデルをいかに実装に落とし込むかにフォーカスしていると感じています。 これはこれで仕方ないと言うか、ドメインの話って広く語れないんですよね。 ドメインは領域で境界があって範囲が限定されています。特定ドメ
こんにちは、サービス開発部のこばやし(eri-twin)です。 BIGLOBEで働いて5年目のサーバサイドエンジニアです。 私は「やりたい仕事で楽しく成果を出す」をモットーに日々働いています。 そしてこの働き方を実現するために、会社の文化や制度にたくさんお世話になっています。 今回はそんな私が会社で関わっているさまざまな活動を通して、BIGLOBEのエンジニア文化を紹介したいと思います! BIGLOBEでは、成長の機会がたくさんある! 勉強できる環境がある! BIGLOBEは、エンジニアの勉強を奨励してくれる会社です。 ↑このスペースの本棚いっぱいに技術書が並んでいます! 技術書の本棚があり、ここの本は会社のお金で購入してもらったものです。 購入タイトルの申請も簡単で、技術書の購入には上司も非常に理解があるため承認もスムーズです。 業務時間内にも定時後にも、ここに並ぶ技術書を眺めたり読んで
はじめに 先日、増田亨さんの「現場で役立つシステム設計の原則」を読んだので感想を。 しばらく前に買っていたのですが、年末で余裕があったのでやっと読了しました。 現場で役立つシステム設計の原則 ~変更を楽で安全にするオブジェクト指向の実践技法 作者:増田 亨出版社/メーカー: 技術評論社発売日: 2017/07/05メディア: 単行本(ソフトカバー) 現場で役立つシステム設計の原則 〜変更を楽で安全にするオブジェクト指向の実践技法 作者:増田 亨出版社/メーカー: 技術評論社発売日: 2017/07/05メディア: Kindle版 現場で役立つシステム設計の原則 概要 全10章で構成されていて、総じてDDDやオブジェクト指向メインの話になっています。 なぜそうするのかという理由とサンプルコードと一緒に説明がなされていて、イメージがわきやすくなっています。 感想 1番の感想は、「新卒1年目で読
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く