2018年8月22日、『神姫PROJECT』などソーシャルゲームの企画・開発を手がける株式会社テクロスが主催するイベント「TECH x GAME COLLEGE」が開催されました。第1回となる今回のテーマは「ドメイン駆動設計の実践」。ドメイン駆動設計（DDD）の基礎知識と、ゲームにおける活用方法について、ギルドワークス株式会社取締役の増田亨氏が解説します。後半では、実際にドメイン駆動設計を開発現場に導入する際の課題の解決策や、来場者からの質問に回答しました。講演資料はこちら オブジェクト指向でモジュール化するとはどういうことか？ 増田亨氏（以下、増田）：「オブジェクト指向でモジュール化する」というのは2番目のテーマですね。 ここはある意味ハードルでして。まずこの議論をするときは、ソフトウェアのモジュールはなんだという話をしたほうがいいと思っていて。 モジュールという言葉はあちこちで使われて

2018年8月22日、『神姫PROJECT』などソーシャルゲームの企画・開発を手がける株式会社テクロスが主催するイベント「TECH x GAME COLLEGE」が開催されました。第1回となる今回のテーマは「ドメイン駆動設計の実践」。ドメイン駆動設計（DDD）の基礎知識と、ゲームにおける活用方法について、ギルドワークス株式会社取締役の増田亨氏が解説します。前半パートとなる今回は、ドメイン駆動設計の基礎的な概念や、既存の設計との違いについて語ります。講演資料はこちら ドメイン駆動設計の基礎知識 増田亨氏（以下、増田）：こんばんは。ギルドワークスの増田です。 実は、テクロスさんとは『UNITIA』の開発初期に京都に隔週ぐらいで何度かお邪魔して、開発チームのみなさんと設計を議論したりしました。そういった縁があって、今日は講師として招かれました。ありがとうございます。 「ドメイン駆動設計の実践」と

Validator クラスなんて考えたこともなかった。 Calculator, Builder, Manager,Reader, Writer,... 最後に -er や -or がつくのは、クラスの設計として、初歩的な避けるべき設計なんだよなあ。 関心事の焦点がずれている。

Clean Architecture 達人に学ぶソフトウェアの構造と設計を読んでます。モデリングに関しては成分薄めですが、よい本だと思います。はい。 Clean Architecture 達人に学ぶソフトウェアの構造と設計 作者: Robert C.Martin,角征典,高木正弘出版社/メーカー: KADOKAWA発売日: 2018/07/27メディア: 単行本この商品を含むブログを見る 本書の大筋から少し逸れるが、「5章 オブジェクト指向プログラミング」の「カプセル化」が面白かったので、これを切り口にモデリングについて考えてみる。 OO言語のカプセル化はすでに弱体化している オブジェクト指向の三大要素の一つである、カプセル化について、以下のようなことが書いてあります。 「カプセル化」がOOの定義の一部となっているのは、OO言語がデータと関数のカプセル化を簡単かつ効果的なものにしているから

Este documento presenta conceptos clave de diseño de dominio y arquitectura de software. Explica patrones como agregados, fábricas y repositorios para modelar entidades y servicios, y describe técnicas como capas de anticorrupción y contextos de dominio acotados para dividir una aplicación. También cubre temas como modelado de eventos, diseño estratégico y mapeo de contextos de dominio.Leer menos

エンジニアの学習と成長◆古い設計スタイルの呪縛を解く４つの合言葉◆「だいたいわかっている」の壁を突き抜ける５つの学習パターン

経緯 何故なのかまったくわからないんだけど、数ヶ月前からTwitter界隈で謎にタカられるようになった。 以下のようなハッシュタグまでできてもう収拾がつかない状態であった。 twitter.com これはこれでネタとしておもしろいし、僕もいろいろ勉強したいこともあるので逆に利用してやろうと思って、 なんとかさんの金で肉が食べたいというハッシュタグが流行ってるんですが、わりと真面目に、僕とペアプロしてくれたらお肉奢りますって言ったら何時間くらいでどれくらいの肉だったらやってくれる人いますかね？もちろん僕より対象言語とかフレームワークとかに精通してる人限定。— すえなみ＠すえなみチャンス？ (@a_suenami) 2017年12月21日 というツイートをしたのがもう半年くらい前。 ついに先日お声がけいただいた。 すえなみさんの奢りで、肉が食いたい。 Javaかつビジネスルール複雑系であれば、

業務がめちゃくちゃ忙しい最中だったが、あしたの現場で役立つ「システム設計の原則」と「越境」のはじめかた - DevLOVE | Doorkeeper に行ってきましたのでメモ 発表メモ speakerdeck.com 上のスライドベースで 現場で役立つシステム設計の原則 の著者 増田さんと カイゼンジャーニーの著者 市谷さん、新井さんの対談形式だったので アジェンダごとに各著者の方々のコメントをさらっとまとめています。 双方から見た本の感想 増田さんから見た「カイゼンジャーニー」 自分が見てきたことがマイルドに再現された感じ 市谷さん、新井さんから見た「現場で役立つシステム設計の原則」 新井さんとしては「増田さんが語りかけてくる」そんな本 市谷さんとしては、今の時代にフィットさせたオブジェクト指向を読み解くための本 何故この本を書いたのか、書いてみてどんな変化が起きたか 「現場で役立つシス

ドメイン駆動設計は原典となる「エリック・エヴァンスのドメイン駆動設計」の初版が2003年と歴史があり、モダンなフレームワークであればその思想を取り入れた設計がなされているにも関わらず、日本語の情報が少ない気がする。 最近ドメイン駆動設計をやろうと主にWeb上の情報を探っていたので参考になったサイトをリンク集の形でまとめてみる。 概要 概要を把握するのが一番難しいように思うので、色々と目を通すのがよさそう。 little-hands.hatenablog.com enterprisegeeks.hatenablog.com enterprisegeeks.hatenablog.com speakerdeck.com ドメイン駆動設計とは何か　【入門編】 from 増田 亨 www.slideshare.net 3週連続DDDその1 ドメイン駆動設計の基本を理解する from 増田 亨 www

この記事を書いたあたりから、よりDDDについて知りたくなって追加で読み始めた本 takanamito.hateblo.jp 現場で役立つシステム設計の原則 ~変更を楽で安全にするオブジェクト指向の実践技法 作者: 増田亨出版社/メーカー: 技術評論社発売日: 2017/07/05メディア: 単行本（ソフトカバー）この商品を含むブログ (1件) を見る 業務におけるプログラミングでオブジェクト指向を実践するにはどうすればよいかを、ここまで具体的に書いてくれてる本は初めてだったので読んでよかった。 1章からいきなりドメインオブジェクトの軽い説明と例示 3章ではドメインロジックをドメインオブジェクトに抽出していく説明 4章ではさらにその手前の、業務フローからドメインオブジェクトを見つけていく手法と、ドメインオブジェクトの育て方 少し飛んで8章ではドメインオブジェクトとAPIレスポンスをどう対応さ

JAWS DAYS 2018 参加してきました！ #jawsdays きたー！ pic.twitter.com/FgEVAmBfio— @ketancho (@ketancho) 2018年3月10日 午前中からお昼にかけて、娘の習い事に行っていたため、午後からの参戦です。数セッションしか聴けませんでしたが、非常に勉強になりましたのでメモを投稿したいと思います。（取ったメモをほぼ修正せずに載せます。誤字脱字などあったらすみません。） 14:00-14:50 ユーザー企業におけるサーバレスシステムへの移行 #jd2018_g なぜ、サーバレスに至ったのか 大規模システムはイヤ システム変更の影響範囲が広いと、機能を追加しようとしたときに「まずは影響調査から」になってしまう。 そうなると、せっかく業務サイドが新しい機能を考えてくれても、「ビジネス的な効果 < 実装工数」となってしまう。 過去に

あるエンジニアがプログラムを紡いでいく様を見てみるでしたライブコーディングで言ったことや言わなかったことを書いてみます。 意識してるのは「コードをどまんなかに」です。 speakerdeck.com ……あ、このスライドのブログ書き忘れてた。 スライド中の「えらぶ」はだいたいIDEの機能を指します。なのでライブコーディング中に使用したIDEの機能も挙げようと思います。基本的にデフォルトのつもりだけど、vimとの兼ね合いで変更してるのもあるので、そこはごめんなさい。あとMacです。今回はメソッド抽出とかクラス間移動とかダイナミックなのがなくて地味だけど、便利な子たちなので使ってあげてください。 リプレイ 今日の公開コーディングはスゴい新鮮だった🎵 コミット後のソースには、どこに悩んだのか、どこにこだわったのかは残らないのですね。 実際のコーディングを見させて頂く事で、気づかされる事が多かっ

現場で役立つシステム設計の原則 ~変更を楽で安全にするオブジェクト指向の実践技法 作者: 増田亨出版社/メーカー: 技術評論社発売日: 2017/07/05メディア: 単行本（ソフトカバー）この商品を含むブログ (1件) を見る 目次流しは以前書きましたが、読み終わってるので改めて。 一緒に開発する人には読んでおいてほしい。可能なら手元に置きながら開発してほしい本です。手頃なサイズ、重量、厚さ、価格ですし。鈍器本系に比べれば持ち運びやすい。実際レビューやペアプロの際、「あの本に書いてるんだけど・・・」という感じで何度か参照しています。 読書会をしてみて 4つのイベントに参加しました。うち2つは輪読形式の読書会で、最初から最後まで読み上げです。有用なのと同時に危険でもある、というのが読書会での感想です。 平易な文章で理解しやすいように思えるのですが、表面だけで理解した気になっていると間違いな

現場で役立つシステム設計と実装、リファクタリングに開発プロセスにOOPとDDDの本 ドメイン駆動設計（DDD: Domain Driven Design）の実践者としても知られる増田 亨さんの2017年7月の本。ネットでもかなり話題になったので読んだ人も多いのではないでしょうか。 現場で役立つシステム設計の原則 〜変更を楽で安全にするオブジェクト指向の実践技法 作者:増田 亨発売日: 2017/07/05メディア: Kindle版 タイトルは「～システム設計～」となっていますが実際は設計以外の話もあるので、もう現場で役立つシステム「開発」全般で役立つ原則本となっています。 技術評論社から各種出ている一般的な技術書サイズで422とボリュームはありますが、内容はかなり推敲されていて文章はとても読み易いです。 サンプルコードはすべてJava。しかし本書で述べられているテクニックはかの『リファクタ

10月頃から、一部有志を集めて学習会を開いていて、その第一弾に選んだ題材が DDD (Domain-driven design) だった。 まだ道半ばであるが、ここいらで一度まとめておきたい。 tl;dr Kotlin, IntelliJ, PlantUML, Spock の使い方の解説はない DDD の解説はない 正しい DDD とは、とかも無いです UDD は、ubiquitous language driven design 造語です DDD を目指しドメイン設計を実施してみて、何が変わったのか 実施前 業務ドメインが分からなすぎた でも、取り敢えず設計・作成するだけならこれでも行けた でも、やっぱり業務知らないと、将来的に辛い お客さんとのメンタルモデルの差を埋める何かが欲しい 実施後 複雑に絡んでいると思った業務が、やってみると意外とそうでもない (と思えるようになった) ユーザ

フューチャーアーキテクト Advent Calendar 2017の2日目です。 はじめに システム設計が大好きで大嫌いな皆さん、こんにちは。 突然ですが、皆さんはどのようにシステム設計における ドキュメント腐る問題 に立ち向かっていますか？ ドキュメント腐る問題とは、設計時に作成した各種ドキュメントがGoogle Driveやファイルサーバ上で陳腐化してしまい、現状の正しい状態を指していないことです。せっかく新規参画者がキャッチアップしようとしてもドキュメントが真実を示していないという怖いやつですよね。 解決策としては、各種ドキュメントを、MarkdownやAsciiDoc、UMLはPlantUMLやmermaid、ERDはPlantUMLやerd、画面遷移図はUI Flow、REST-API設計はSwaggerなど、なるべくテキストベースで管理し、GitHubなどのリポジトリで管理する

little-hands.hatenablog.com こちらの記事で説明できなかった、「境界づけられたコンテキストをどうやって実装に落とし込むのか？という話を書きます。 境界づけられたコンテキスト実装の基本イメージ 結論からいくと、基本的には、 1コンテキスト = 1アプリケーション と思ってもらってOKです。 これを基本として、用途や実装コストと相談しながら少しずつ設計を組み替える検討が可能です。 1アプリケーション単位で、オニオンアーキテクチャ概略の記事で紹介したアーキテクチャを1セット揃えると思ってください。 つまり、こちらの記事で紹介した2つの境界づけられたコンテキストに対して、 以下のようにアプリケーションを2セット作ります。 ドメイン層を外界と隔離して、外部に公開するする操作を周りの層で定義するのです。 最終的に、マイクロサービス2つ作ると思ってもらって良いです。そうすると、

この記事はCrowdWorks Advent Calendar 2017の4日目の記事です。 はじめに 今年CrowdWorksにエンジニアとして新卒入社した@kinakoboです。CrowdWorksでは10月から新たな試みとしてドメイン駆動設計（DDD）を実践しています。 DDDを実践するに至った経緯は、サービスの規模拡大に伴いアプリが肥大化し、技術的負債が増えてきたことで、機能追加をスピーディーに進めづらくなってきたからです。 今回実装しようとしている機能を今まで通りRuby on Railsを利用して実装することは可能ですが、変更に強い柔軟なサービスにするためにもDDD+Scalaで実装し始めています。 DDD未経験の状態から2ヶ月実践してみて、まだ道半ばですが感じたことを書きます。同じような課題感を持っている方の参考になれば幸いです。 エヴァンス本に挫折したら･･･ DDDと言え

境界づけられたコンテキストとは 公式DDD Referenceの定義は以下の通りです。(和訳はだいぶ意訳しています) bounded context A description of a boundary (typically a subsystem, or the work of a particular team) within which a particular model is defined and applicable. 境界づけられたコンテキスト 特定のモデルを定義・適用する境界を明示的に示したもの。 代表的な境界の例は、サブシステムやチームなど。 まぁなかなかよくわからないですよね。DDD用語の中でもかなり難解なワードです。 境界づけられたコンテキストは、2つの観点から解説が必要でしょう。 ・概念としての境界づけられたコンテキスト ・境界づけられたコンテキストをどう実装に