受付中のDDDの導入サポート[ドメイン駆動設計] - little hands' lab
DDD関するトピックを中心にオンライン研修、チャットサポートをご要望ベースで実施しております。ご相談は @little_hand_sのDM、もしくはお問い合わせフォームまでお願いいたします。 DDD導入サポート ①ライブモデリング、ライブコーディング研修(zoom開催) ご相談いただく方の現場の題材でモデリングから実装までを簡易的に一通り行い、DDDの全体像を把握していただくことができます。 モデリング、コーディングそれぞれ所要時間は約2時間です。片方のみ実施も可能です。 DDDの基礎知識については、事前に座学コンテンツはこちらの動画を見ていただいています。 DDDオンライン勉強会 #1 「モデリング/実装入門」 - YouTube こちらで基礎的な認識は揃えていただけるので、 直接お話しする時はより具体的な内容をできるようにしています。 アンケートで、よかった点として以下のようなご意見を
![受付中のDDDの導入サポート[ドメイン駆動設計] - little hands' lab](https://cdn-ak-scissors.b.st-hatena.com/image/square/b397d381a703bf1b272e6057f37adf63354d10fd/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F11696248318756265553%2F26006613445034697%2F1626667914)
役割駆動設計で巨大クラスを爆殺する - Qiita
大量のメソッドを保有し、数千、数万行単位にぶくぶく膨れ上がった巨大クラス。別名「神クラス」とも「大きな泥団子」とも呼ばれる、長大で複雑で密結合で極めて変更が困難なアイツ。 そんな巨大クラスの退治に有効な、ドメイン駆動設計を基本思想とする「役割駆動設計」を紹介致します。 解決したい課題、狙う効果 数千、数万行単位の巨大クラスの登場を抑止する。 小さくシンプルな構造に落とし込み、堅牢で変更容易性の高い設計へ昇華させる。 例１：筆者をモデリング 分かりやすくなるよう、まず私を例にモデリングしてみます。私は以下のような特徴があります。 IT企業の従業員 家族がいる(妻, 子供) 趣味でゲーム制作している ダメな設計 何も考えずに人クラスとして設計すると、よく以下のような構造になりがちです。 従業員として仕事をする、父親として家族サービスする、趣味としてゲーム制作する、それぞれのメソッドが備わってい
「DDD」にまつわる諸課題の整理 - Qiita
DDD的なことを今後進めていく上で、自分として課題としている論点をまとめてみた。あくまで私の現時点での理解度を前提に、そこでの個人的課題感を取り纏めてみたものなので、不足や誤りや過剰が多々あるだろうがご容赦を。そして、アドベントカレンダーの初日、続く議論の礎となり、3人の賢者24人の荒ぶる者によってベツレヘムの星が見出されることをただ願うのである。 ◇ あらまし DDDのいわゆる戦略の言う“広義のドメイン”と、戦術パターンにおける“狭義のドメイン”。この二つの用語は、実のところ「異なる境界付けられたコンテキストに属する語彙」として扱った方がよいのではないか？ 参照系と更新系は、その本質として非対称性があって、参照系向けの新たな戦術パターンが必要なのではないか？ 「コンテキスト」は、強く分離する上位階層から緩く分離する下位層まで、多段階の階層構造に在ると捉えるべきではないか？ （「3.」を前
DSL開発：ドメイン駆動設計に基づくドメイン固有言語開発のための７つの提言 - Johan den Haan - Digital Romanticism - digitalsoulのブログ
この記事はJohan den Haan氏のブログ記事「DSL development: 7 recommendations for Domain Specific Language design based on Domain-Driven Design」を氏の許可を得て翻訳したものです。（原文公開日：2009年5月6日） ドメイン固有言語（DSL）という用語は今日多く聞かれる。DSLとは与えられたドメインの要求に対処するために開発される言語である。ドメインは問題領域（例えば、保険、健康管理、運送）である場合もあれば、システム的な側面（例えば、データ、プレゼンテーション、ビジネスロジック、ワークフロー）である場合もある。これは制限された概念を用いて言語を作るという考え方であり、これらの概念は特定のドメインに焦点を絞ったものである。この考え方により、開発者の生産性とドメインエキスパートとのコ
「関心事」と「責務」 の お話
5. ●James Lewis氏によって2014年頃に提案された言葉 ●氏の提唱する特徴 ○ サービスによるコンポーネント化 ○ ビジネスケイパビリティに基づく組織化 ○ プロジェクトではなくプロダクト ○ スマートエンドポイントとダムパイプ ○ 分散型ガバナンス ○ 分散データ管理 ○ インフラストラクチャ自動化 ○ 障害設計 ○ 進化的設計 マイクロサービス - Microservices https://martinfowler.com/articles/microservices.html 6. スマートエンドポイントとダムパイプ 異なるプロセス間でのコミュニケーション構造を ●スマートエンドポイント ○ RESTishなリソースAPI ●ダムパイプ ○ RabbitMQ や ZeroMQ などの軽量メッセージングダム （メッセージルータ）を通じて通信を行う を用いて構築する ht
【感想】 現場で役立つシステム設計の原則 - Rのつく財団入り口
現場で役立つシステム設計と実装、リファクタリングに開発プロセスにOOPとDDDの本 ドメイン駆動設計（DDD: Domain Driven Design）の実践者としても知られる増田 亨さんの2017年7月の本。ネットでもかなり話題になったので読んだ人も多いのではないでしょうか。 現場で役立つシステム設計の原則 〜変更を楽で安全にするオブジェクト指向の実践技法 作者:増田 亨発売日: 2017/07/05メディア: Kindle版 タイトルは「～システム設計～」となっていますが実際は設計以外の話もあるので、もう現場で役立つシステム「開発」全般で役立つ原則本となっています。 技術評論社から各種出ている一般的な技術書サイズで422とボリュームはありますが、内容はかなり推敲されていて文章はとても読み易いです。 サンプルコードはすべてJava。しかし本書で述べられているテクニックはかの『リファクタ
ドメイン駆動設計を始めるために必要なチームのつくり方
Gunma.web #30のLTで発表した資料です。 どうすればドメイン駆動設計を導入出来るのか、というところにフォーカスにして考えてみました。
内なる秩序の探求〜テスト駆動開発をやめて、なお残すべき習慣とは(7)
はじめに前回は、外側のテストループについて何を作ればよいかの探求について解説しました。今回は、実際に「どう作ればよいか」について、コードや設計の内側の秩序の探求について解説します。 TDDの肝は、動作するきれいなコードを目標に、テスト書いて、 実装して、学んで、リファクタリングして… を小さく繰り返し、内なるコードや設計の秩序化するステップを踏み続けることにあります。では、「動作するきれいなコード」と呼ばれる目指すべき場所は何を頼りに向かえば良いのでしょうか？ プログラミングにはコードや設計の秩序化を図るための定石が幾つか知られています。例えば、UNIXの設計判断（例：一つのプログラムには一つのことをうまくやらせる）、メタファ、名前重要、DRY原則、SOLID原則、KISSの法則、コマンドクエリの分離原則、契約による設計、オブジェクト指向のイディオム、関数型のイディオム、各種の言語やフレー
ドメインモデルの根拠とドメインモデル貧血症の対策について - Chatwork Creator's Note
ChatWork Advent Calendar 2017の10日目の記事です。 こんにちは。かとじゅん([Twitter:@j5ik2o]) です。 何を書こうかと悩んだのですが、社内で意見を聞いたところ、やはりDDD関連がよいとなりました。 Scalaコードでわかった気になるDDD この記事も、もう四年前ですっかり古くなりました。最近どういう観点で実践しているかまとめてみます。(DDD初級者という方は、まず上の記事を読むことをお勧めします) DDDを実践するにあたっての個人的な問題点は2つあります。ひとつは、「いきなりドメインモデルを作ることができない」という問題。もうひとつは、ドメインモデルを作り上げても実装コードに役に立つ振る舞いが思いつかず、いわゆる「ドメインモデル貧血症*1」になりやすいという問題です。このような問題は、僕がコミュニティで関わった多くのエンジニアから耳にします。
DDD with RDRA, ICONIX
DDDを具体的なプロセスに落とし込むにはどういう観点が必要だろうか。 - 境界づけられたコンテキストがどこまでの範囲かよくわからない - ユビキタス言語やドメインモデルをどのように発見すればいいかわからない。どこから着手すればいいのか？ - ドメインモデルがただのデータの入れ物になってしまう(貧血症) という問いに答えるには、RDRA, ICONIXを検討するとよいというテーマの資料です。
ドメインオブジェクトの見つけ方・作り方・育て方
3. オブジェクト指向設計の 考え方とやり方 オブジェクト指向エクササイズ ９つのルール モジュール性 ５つの基準 抽象データ型 契約による設計 コードのいやな臭い その改善策１章 ドメインを学ぶ ２章 言葉を使う ３章 モデルと実装を結びつける ４章 ドメインを隔離する ５章 モデルを表現する部品 １０章 しなやかな設計 ４冊とも、想定読者はオブジェクト指向でコードを書く人 それぞれが関連している 今日は実践例として紹介してみたい
無限のメモリ空間と絶対に落ちないプロセスを仮定して「ビジネスロジック」をあぶり出す - assertInstanceOf('Engineer', $a_suenami)
先日、前職の上司から「そろそろプロフィールに"詩人"を追加するべきだ」と言われました a-suenami です。今日も今日とて詩人業を行なっていきますよ！ 「ビジネスロジック」とは何か 最近、業務で、比較的中長期的なアーキテクチャの見直しだったり、新機能の設計だったりをさせてもらう機会が増えた。 コンポーネントをどういう風に分割するかとか、それぞれのコンポーネントを主にどのチームでメンテナンスしていくかとか、そういうのを考えるのは楽しい反面、かなり熟慮に熟慮を重ねないといけないものでもあるのでかなり責任を感じるというのもある。 まあ、そんなこんなでいろいろうーんうーんって悩んでいると昔（たぶん DDD コミュニティだと思うけど）誰かに言われた「無限のメモリ空間と絶対に落ちないプロセスがあったとして、それでもそのコードを書かないといけないのならそれがあなたのドメインだ」という言葉だ。 モデリ
ドメイン駆動設計を取り入れてみて感じたこと。 | FiNC Developers Blog
ドメイン駆動設計を取り入れてみて感じたこと。 はじめまして、FiNCのWeb Applicationエンジニアの重村です。 ウェルネスサーベイというサービスを作っています。 FiNCではマイクロサービスと呼ばれるアーキテクチャパターンを積極的に採用しており、十数個のサービスがあります。 私が担当している「ウェルネスサーベイ」は、FiNCが提供している主軸サービスに導入されている重要なサービスになっており、使いやすい機能やわかりやすいデザインを考えるだけでなく、良い設計や保守性の高いコードを書くことを求められます。 そこで私はドメイン駆動設計という良いコードを書くためのノウハウを、このプロジェクトに取り入れようとしてきました。 今回は、プロジェクトに取り入れたドメイン駆動設計の5つの方法と、それらに対して感じたことを紹介したいと思います。 ドメイン駆動設計の知識や考え方ついては、以下の資料に
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
クラシコムとLaravelとDDD
Spring BootとKafkaでCQRS - Speaker Deck
ドメイン駆動設計基礎講座〜戦略編〜
DDDパターンを活用した Laravelアプリケーション開発/ddd-with-laravel
Designer meets Domain-Driven-Design
メンタルモデルから紐解く オブジェクト指向的コンポーネント設計 / Mental-Model Component Design
DDDってなんだろう？
