レガシーをぶっつぶせ。現場でDDD!の資料になります。 https://genbade-ddd.connpass.com/event/127494/
きっかけ JSUGの勉強会に行ってまいりました。 Spring BootベースのDDDサンプル徹底解説! jsug.doorkeeper.jp 題材は、このリポジトリの解説とJIGというツールの紹介でした。 GitHub - system-sekkei/isolating-the-domain: architecture sample using : Spring Boot gradle, Spring MVC, Thymeleaf, and MyBatis もともと発表者の増田さんの本は読んでいて、実際にギョームアプリに適用できるかは方針によるんだけどアプリケーションのあるべき方向性みたいなものの指針にはしていました。 (言い方があれなんだけれども結構、振り切った設計をしていて、アプリの方針によっては取捨選択が必要な感じ) 結構極端に思えるんだけど、設計方針にすべて明確な理由付けがあって
ボトムアップドメイン駆動設計 後編 1. ボトムアップ ドメイン駆動設計 後編 成瀬 允宣2018/10/23 in GMO Yours 1 2. 自己紹介 • 成瀬 允宣 - Masanobu Naruse • プログラマ • C#, Scala, Typescript • DDD とかアーキテクチャの話が好きです • @nrslib • https://nrslib.com 2 3. もくじ • はじめに • 値オブジェクト • エンティティ • ドメインサービス • リポジトリ • アプリケーションサービス • ファクトリ • トランザクション • 集約 • アーキテクチャ • ドメイン駆動設計への誘い 3 4. 閑話休題 4 アプリケーションが 作れるようになりました ここから後半です 5. ファクトリ 5 後半最初のテーマは ファクトリ 6. ファクトリ | 採番 6 サンプルの
怖さの原因は? 辛さの原因は? ドメイン駆動設計の用語は2パターン 挫折した方がもう一度手に取ってみたいと思ったら、私の勝ちです C# だと比較ってこんな感じに実装します 勿論こんなこと毎回やってられませんから どうなりますか? コードで表すと 識別子の値オブジェクトを作って(任意 その値オブジェクトを識別子にする 同じ属性でも 名字を変更しました 識別子を使います 例えば‘ MySql を使うと 注目すべきは このコンストラクタで受け取った userRepository これが InMemoryUserRepository か UserRepository かで動作が変わる アプリケーションサービスはユースケースを強く意識します ボトムアップドメイン駆動設計 前編 1. ボトムアップ ドメイン駆動設計 成瀬 允宣2018/10/23 in GMO Yours 1 2. 自己紹介 • 成瀬
2018/9/26(水)、「レガシーなコードにドメイン駆動設計で立ち向かった5年間の軌跡」というイベントに参加しました。 ddd-alliance.connpass.com BIGLOBE様の販売システムに対して、ドメイン駆動設計を適用していった実際のお話が聞けるイベントでした。 「ブログ書きます」枠で参加させていただきましたので、イベント内容等について書きます。 ドメイン駆動設計(DDD)とは 私なりの説明ですが。 説明するのは難しいのですが、システムが対象とするドメインに集中するための一連の技法、といえます。 ドメインを正確に表現するために、 開発者とドメインエキスパート間で使うユビキタス言語の作成 ユビキタス言語とソースの用語を一致させる レイヤー化 等の手段が取られます。 上の説明が正しいかどうかわかりませんが、実際は非常に難しいです。 いわゆる「エヴァンズ本」といわれる以下の書籍
2018年8月22日、『神姫PROJECT』などソーシャルゲームの企画・開発を手がける株式会社テクロスが主催するイベント「TECH x GAME COLLEGE」が開催されました。第1回となる今回のテーマは「ドメイン駆動設計の実践」。ドメイン駆動設計(DDD)の基礎知識と、ゲームにおける活用方法について、ギルドワークス株式会社取締役の増田亨氏が解説します。前半パートとなる今回は、ドメイン駆動設計の基礎的な概念や、既存の設計との違いについて語ります。講演資料はこちら ドメイン駆動設計の基礎知識 増田亨氏(以下、増田):こんばんは。ギルドワークスの増田です。 実は、テクロスさんとは『UNITIA』の開発初期に京都に隔週ぐらいで何度かお邪魔して、開発チームのみなさんと設計を議論したりしました。そういった縁があって、今日は講師として招かれました。ありがとうございます。 「ドメイン駆動設計の実践」と
日本語版『エリック・エヴァンスのドメイン駆動設計』p.3の、「ドメイン駆動設計におけるモデルの有用性」の部分、大事なことを言っているような箇所なのに、文章のつながりや意味がイマイチとれなかった。そこで原著Kindle版を購入し、原文から自分なりに訳してみた。(私の訳文は若干補足的な文章になっている) なお、この箇所は見出し(効用/有用性)と、中の箇条書きの構造とがマッチしていないので読みづらいのだと思う。各箇条書きの最初の文が「基本的使用方法」、つまり、モデルに求める条件となっていて、それを満たすとどのようなありがたいことがあるのか(=効用/有用性)の説明が続く、という構造なのだと思う。 The Utility of a Model in Domain-Driven Design ドメイン駆動設計におけるモデルの効用 In domain-driven design, three basic
SoR 2.0 って何だろうというのと RDRAに興味があるというのと 増田さんの お話を聞ける というところで いくつも興味があって tagile.doorkeeper.jp に行ってきました。 基幹システムと向き合いながら、SoEを構築する 以前はスタートアップからの問い合わせが多かったけど 最近は大企業。 (アジャイルによる開発を試みることが前提になりつつあるということかな?) SoRに最適化されているので 簡単にSoEにシフトできるわけではない。 現状は社内受託開発みたいな感じでビジネスの中心にソフトがない。 (残念ながら)本当の意味のCTOではないケースが多い。 体制を つくるのにはコストが必要 SESのように 人を埋めること(空要員をつくらないこと)が正しいという世界から いきなり変えられるものではない。 大切を作るためのコストへの提案 SoEが既にできる傭兵チームを固定化する
It is my pleasure to announce that I have just joined the developer advocacy team at Pivotal, focusing on Spring. I feel privileged to have the opportunity to learn and collaborate with great and passionate engineers from all over the world. Hence, I must say I am really excited for the upcoming journey. If you would like to follow me, I tweet under @JakubPilimon and blog here. Before joining Pivo
ドメイン駆動設計で実装を始めるのに一番とっつきやすいアーキテクチャは何か - 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.
This document contains a collection of images and text snippets related to software development. Some of the images show people working collaboratively, taking notes, thinking, or programming. Other images depict more abstract concepts like evolution, complexity, and growth. The document also includes links to a GitHub repository and slideshare presentation about software development.Read less
We Are JavaScripters! @6th https://wajs.connpass.com/event/54667/
前編ではDDDの概要についてふれたが、後編ではDDDの適用Stepを3つのStepに分けて紹介する。 まずStep1として、アプリケーションに登場しうる概念を抽出してドメインモデルで表現する。 次にStep2として、各ドメインの概念を深掘りしてソフトウェアとしてどう表現するかにについて紹介する。 最後にStep3でドメイン部品の仕上げとDDDの恩恵ついてふれていく。 Step1: ドメインモデルによる表現 DDDでは機能やユースケースに加えて、その裏に潜んでいる「概念」を抽出する必要がある。そのため、DDDを導入するにあたってアプリケーションに登場しうる概念を整理した「ドメインモデル」がまず必要となる。全体のコンテキストを整理して、該当のドメインモデルを描くことがDDDの最初の1歩となる。 例として、よくある一般的な受注管理の簡単なドメインモデルをあげる。 「顧客」からある「商品」の「注文
ドメインロジックに焦点をあてる。 それが、ドメイン駆動設計の基本。 ドメイン駆動設計の考え方とやり方の説明と、実践基盤としての Spring Framework/Spring Boot を使った事例の紹介。Read less
DDDとCQRSとSpring Cloudで、進化してくようなアーキテクチャを作ってくのが良さそう!ってお話。Ignite Talkっていうスタイルの発表で、15秒に1スライド自動でめくられて5分間喋るす。スライド20枚分ね。 圧倒的に英語でのアドリブチカラがないので、泣きながら全力暗記で臨んだものの、何度か頭が真っ白になってますw。ほんとはもっとかっこよくきめたかったので、すごい悔しかったの覚えてるけど、おかげで頭の整理もできたし、英語も少し上手になったし、何人かと喋ることもできたし、やって良かったなー。 youtu.be ↓これ、その当時かいたの bufferings.hatenablog.com
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く