このスライドでは、ドメイン駆動設計の手法を用いて、 モデリングで機能性を高め、 アーキテクチャと実装パターンで保守性を高める方法を紹介します。 ドメイン駆動設計のモデリング手法として、シンプルな4つの図でモデリングできる"sudoモデリング"の事例を紹介し、それをコードに落とし込むためにどのよ…
このスライドでは、ドメイン駆動設計の手法を用いて、 モデリングで機能性を高め、 アーキテクチャと実装パターンで保守性を高める方法を紹介します。 ドメイン駆動設計のモデリング手法として、シンプルな4つの図でモデリングできる"sudoモデリング"の事例を紹介し、それをコードに落とし込むためにどのよ…
目次 概要 この記事の内容 対象読者 注意事項 前提知識 定義 用途 モデリング 不変性 独立性 汎用情報 個別の情報 Versioning 実装 前提 フレームワーク Domain Eventの処理 型定義 interface DomainEventEnvelope Enum Domain Eventの内部通知 staticなEvent Publisherを用意してAggregateがPublisherを呼び出す 実装例 AggregateのCommandの返り値としてDomain Eventを返す 実装例 Aggregateで保持してGetterで取り出す 実装例 永続化と外部通知 要件 永続化 外部通知 まとめ 参考文献 概要 この記事の内容 Domain Eventは非常にシンプルな概念かつ強力なモデリングパターンです。 モデリングにおいては直感的に扱うことが可能ですが、実装をする
2018年8月22日、『神姫PROJECT』などソーシャルゲームの企画・開発を手がける株式会社テクロスが主催するイベント「TECH x GAME COLLEGE」が開催されました。第1回となる今回のテーマは「ドメイン駆動設計の実践」。ドメイン駆動設計(DDD)の基礎知識と、ゲームにおける活用方法について、ギルドワークス株式会社取締役の増田亨氏が解説します。前半パートとなる今回は、ドメイン駆動設計の基礎的な概念や、既存の設計との違いについて語ります。講演資料はこちら ドメイン駆動設計の基礎知識増田亨氏(以下、増田):こんばんは。ギルドワークスの増田です。 実は、テクロスさんとは『UNITIA』の開発初期に京都に隔週ぐらいで何度かお邪魔して、開発チームのみなさんと設計を議論したりしました。そういった縁があって、今日は講師として招かれました。ありがとうございます。 「ドメイン駆動設計の実践」とい
DDD連載記事 背景・前提 なぜDDD初心者はググリ出してすぐに心がくじけてしまうのかの記事で、 ネット上の文献で紹介されるアーキテクチャが様々なものとなっているのです。IDDDではヘキサゴナルアーキテクチャというものが掲げられていましたが、それを進化させたオニオンアーキテクチャ、クリーンアーキテクチャなどの有名な亜種が存在します。 これが実装に着手する際に非常に大きな混乱を呼ぶのです。文脈の理解、採用するアーキテクチャの選定に時間を取られることでしょう。 と書きました。こちらに対して、私が「一番とっつきやすい」と考えるアーキテクチャを紹介します。 前提としてですが、完全に個人的な経験に基づく私見になります。 DDDの理論の中で、アーキテクチャに関しては「エリック・エヴァンスのドメイン駆動開発」(以下原典)と実践ドメイン駆動開発(以下IDDD)とでも異なったものが紹介されており、唯一の正解
little-hands.hatenablog.com こちらの記事で説明できなかった、「境界づけられたコンテキストをどうやって実装に落とし込むのか?という話を書きます。 境界づけられたコンテキスト実装の基本イメージ 結論からいくと、基本的には、 1コンテキスト = 1アプリケーション と思ってもらってOKです。 これを基本として、用途や実装コストと相談しながら少しずつ設計を組み替える検討が可能です。 1アプリケーション単位で、オニオンアーキテクチャ概略の記事で紹介したアーキテクチャを1セット揃えると思ってください。 つまり、こちらの記事で紹介した2つの境界づけられたコンテキストに対して、 以下のようにアプリケーションを2セット作ります。 ドメイン層を外界と隔離して、外部に公開するする操作を周りの層で定義するのです。 最終的に、マイクロサービス2つ作ると思ってもらって良いです。そうすると、
あなたにとって重要なトピックや同僚の最新情報を入手しましょう最新の洞察とトレンドに関する最新情報を即座に受け取りましょう。 継続的な学習のために、無料のリソースに手軽にアクセスしましょうミニブック、トランスクリプト付き動画、およびトレーニング教材。 記事を保存して、いつでも読むことができます記事をブックマークして、準備ができたらいつでも読めます。
日本のDDD(ドメイン駆動設計)界の父ともいえる増田亨さんが著した「現場で役立つシステム設計の原則」を頂いたので、早速拝読させていただきました。 本書をおすすめしたい人 本書は、システム開発で以下のような問題を抱えている人におすすめです。 既存システムのソースコードの可読性が低く、理解に時間がかかる 機能追加・改修時の影響範囲調査に時間がかかる 機能追加・改修時の工数が予想以上にかかる テストコードが書きにくいソースコードになりがち 機能を追加・改修時の影響範囲が大きくなりがちで、テスト工数がかさんでいる デグレの確認に気を使い、多くの時間をかけている 不具合が発生したときに、調査・解決に時間がかかってしまう 新しいメンバーがプロジェクトに参画した時に、業務知識を伝えるのに多くの手間がかかる これらの問題のために、生み出す価値以上に、仕事時間が増えている このような問題を解消し、変更に強い
In my previous post I introduced the concept of Event Sourcing, which is a radically different way of storing application state: instead of storing the current state, we only store the events that lead up to that state. More than one person asked the following question in response: how do you query your application state? If you have a number of appointments in your system, how do you get a list o
はじめに ドメイン駆動設計(DDD)とは、2003年にエリック・エヴァンス氏が『Domain-driven design』という書籍にて提唱したソフトウェア開発手法です。DDDを簡単に説明すると「顧客と開発者が業務を戦略的に理解し、共通の言葉を使いながらシステムを発展させる手法」です。具体的には、チームの共通言語である「ユビキタス言語」を用いて「ドメインモデル」を構築し、それをコードとして実装します。また大規模で密結合なシステムにならないように「ドメイン」と「境界づけられたコンテキスト」にてシステムを分割し、「コアドメイン」という最重要領域に集中して開発を行います。 ソフトウェア開発の課題とDDDが解決すること DDDの登場から10年以上が経ち、DDDは着実に普及しつつあります。DDDが普及してきている背景として、システム開発がますます多機能/複雑になり、ビジネス的にも敏速な変更が求められ
Reactive Messaging Patterns読書会のなかで、「マイクロサービスとAkkaとGo」な面白い話題が出たので代表でまとめる試みエントリです。(結構、色々な話題に飛んでいるので難度高い。) まとめ方としては、会話ログを転記して、最後にまとめる形をとっています。また、議論と私の考えが混ざらないように所感は分けておきます。 ddd-cqrs-es.connpass.com TL;DR 要素技術(どんな言語使うとか、どんなアーキテクチャにするとか)の前に、組織やプロダクトの性格を考えて戦略を決めましょう。 そして、その中で最適と思われる戦術をとれるような要素技術を採用しましょう。 Akka良いよ。 ログ(一部抜粋) Slackからの引用のためテキストベースです。 事の始まりは、荒木さん(以下、 @applideveloper )の発言でした。 (この記事絡みですね。 集合知で各
Not your computer? Use a private browsing window to sign in. Learn more about using Guest mode
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く