#fukabori をきいて Value Object と Value Object パターンについて頭の中を整理 - Mitsuyuki.Shiiba
連休の余韻も楽しんだので今日から散歩を再開した。ちょっと前までは「陽の光を浴びなきゃ！」と思って3時過ぎにウロウロしてたけど、これからはもうちょっと涼しい時間帯がいいなと思って、夕暮れ時に散歩しながら fukabori.fm を聴いてた。Value Object のお話。面白いなぁ 73. Value Object w/ kumagi | fukabori.fm kumagi さんの記事はこちら Value Objectについて整理しよう - Software Transactional Memo お絵描き PoEAA や DDD はだいぶ前に読んだことがあるけど、Value Object を雰囲気で捉えてるからちゃんと見直しておこうと思って、調べたりしながら絵を描いた。こういうことなのかな？ （絵をかくほどでもなかった・・・ Value Object とは？ kumagi さんも書いてる
集約の実装について考えてみた
はじめに DDD の集約の実装について考えたことをまとめます。 題材 料理のレシピ作成を題材としてまとめていきたいと思います。 概要 概要は以下の通りです。 レシピには材料と作り方がある。 材料には食材や調味料などの名前と分量が必要である。 材料はメインとなる材料や合わせダレなどのカテゴリごとにグルーピングできるとよい。 作り方は具体的な手順を示すものである。 ドメインモデル 上記をドメインモデルで表現するとこのようなイメージです。 各種値の範囲はドメインとして決まっているわけではないですが、システム化する上で決めなければならないことだと思いますので、ドメインエキスパートとすり合わせながら運用に支障をきたさない範囲で決定すると良いのかなと思います。 今回は決定した値の範囲をドメインモデルに補足する形で記載しています。 ユースケース システムに対するユースケースは以下の通りとし、末端のユース
フロントエンドとオブジェクト指向
フロントエンドの実装にオブジェクト指向をどのように取り入れるかを考えます。 動機 近年のフロントエンドは、Reactなどのフレームワークを使ったコンポーネントベースの設計が主流だと思います。コンポーネントは、HTMLによるマークアップ、CSSによるスタイリング、JavaScriptによる振る舞いがひとまとめにされた、再利用可能な部品です。 コンポーネントの設計を考えていると、次のような疑問が生じます。 何を基準にコンポーネントで分割すればよいか。 コンポーネントの粒度はどれくらいが適切なのか。 どのタイミングで抽象化すれば開発コストが無駄にならないか。 分業した際にコンポーネントの分割や粒度の基準をどのように統一するべきか。 そこで、いろいろ調べたり試したりしたところ、フロントエンドの設計にオブジェクト指向を取り入れることが、これらの答えの一つになるのではないかと考えました。 この記事では
本記事は ドメイン駆動設計#1 Advent Calendar 2019 19日目の記事です。 こんにちは、レガシーコードを 爆殺 リファクタリングするのが大好きなミノ駆動です。 今回はドメイン駆動設計導入上避けては通れない、大事な大事なお金の話を致します。 「ドメイン駆動設計を導入してみたいんです！」 部下「ドメイン駆動設計を導入してみたいんです！」 上司「それって何？なんのために導入するの？」 部下「…………」 はい、僕にもそんな時代がありました。 何のためにドメイン駆動設計を導入したいのか、簡潔に説明できますでしょうか。 「ドメイン駆動設計」のタイトルにあるように、本書は設計に関する書籍です。 ソフトウェア全体の設計手法や思想に関して言及している書籍です。 まずはソフトウェアの価値とは何か、設計とは何か、それぞれ何かを整理してみます。 ソフトウェアの価値 ソフトウェアが満たすべき要件
この記事について 先日 DDD-Community-Jp の DDD Talk MeetUp #2 というイベントでトーク枠にて参加させて頂き Flyweight DDD というアーキテクチャスタイルの提案とする一つのスライドを発表させて頂きました。 https://speakerdeck.com/hirodragon112/ddddao-ru-nita-miqie-renaifang-hezeng-ru-2ceng-plus-cqs-akitekutiya-flyweight-ddd ただ、本稿はこのスライドの「内容」とは全く関係ありません。 本稿で取り上げたいのはこのタイトルに登場している CQSという単語についてです。 このスライドをきっかけにCQSとCQRSの違いについて自分なりに思考の整理を記載したいと思います。 CQS ? CQRS ? きっかけは twitter にて @j5
背景 マイクロサービスアーキテクチャが浸透し、それに伴いDDDを導入する企業も増えている気がします。 それと同時に、アクターモデルの話題も最近以前より聞くようになった気がします。 ただ、以下のような疑問を持つ人は多くいるのではないでしょうか？ アクターモデルは聞いたことがあるけど、重要性が分からない 使い所が分からない サーバーレスコンピューティングなの？でもAkkaの説明ばかり出てくるけど？ こういう状況になっている要因の一つは、おそらく、アクターモデルの説明の多くが分散システムにフォーカスしており(当たり前なんですが)、アプリケーションアーキテクチャとの関係性については、使う人まかせになっているためではないでしょうか。 ここでは、アプリケーションアーキテクチャと合わせて、アクターモデルの使い所を考えてみます。 先に結論 アクターモデルは、分散環境で実行するアプリケーションを開発するため
各アクターのメンタルモデルと、複数のアクターが共用する"ドメインモデル"には情報構造上のギャップがある まず最初に、天重氏（@tenjuu99）による次の記事を参照する。 MVCとは何か ぜひ全編を読んでいただきたい。以降読んでいただいた前提で書く。 中盤《2. ドメインモデル》で、飲食店での複写式伝票の話をしている。下に記事中の図を引用させていただく。 この複写式伝票は、ある一つのドメインモデルを"実装"している、といえる。天重氏は、「この注文伝票をぼくが面白いとおもったのは、厨房の人とホールの人で情報構造が違っている点です。」と言っている。 ホールの人にとっての情報構造： ・席番号と料理の紐付けに関心がある。 厨房の人にとっての情報構造： ・料理を出す順番に関心がある。 （席番号と料理の紐付けに制約されずに、料理を出して行きたい。） そして、この複写式伝票は、 両者の情報構造の違い（と
ドメイン駆動設計のマイクロサービスへの活用とデベロッパーに求められるスキルのスライド / DDD session slide in AWS Dev Day Online Japan 2021
AWS Dev Day Online Japan 2021 のパネルディスカッション 『ドメイン駆動設計のマイクロサービスへの活用とデベロッパーに求められるスキル』 で利用したスライドです 自己紹介→マイクロサービスでどうしてDDD？→学習ルート # URL AWS Dev Day Online Japan 2021: https://aws.amazon.com/jp/about-aws/events/2021/devday/ YouTube: https://www.youtube.com/c/narusemi HomePage: https://nrslib.com Twitter: https://twitter.com/nrslib
ドメインをモデリングしてPHPコードに落とし込む / domain-modeling-with-php8
PHP カンファレンス 2021 / フィードバックはこちらへ https://joind.in/talk/650b0
peing.net メッセージングシステムのお題のようです。面白そうなのでちょっと考えてみよう。 問題提起 集約候補が以下の3つ。 ユーザー 企業 スレッド メッセージ スレッド集約はメッセージを複数保持するようです。 1000件のメッセージを保持するスレッド集約を更新した際、1000件のアップデートが行われる スレッド集約内部で更新された属性を把握していない場合は、リポジトリでは全メッセージ分の更新となる。これを避けるための仕組みはどう実装するのか？ ということが指摘されている。まぁわかります。これはCQRS/ESなら解決できるよと言ってみる 問題の分析 で、僕ならどう考えて実装に落とすかつらつらまとめてみよう。CQRS/ES前提です。Akkaの成分は少なめでScalaの擬似コードで解説します。コードはコンパイルしてないので…おかしなところあるかも。 問題はスレッド集約がメッセージの集合
2023.09.14 asken withミライトデザインのDDDのはじめ方 DDD x RDRA x ICONIX https://asken.connpass.com/event/293085/
ドメイン分析とモデル化ここで「モデル化」と呼ぶのは、実装者が理解しやすいように重要な側面に注目して、端的な形に抽象化する行為であると定義します。 また、実際に実務で行なっている自身のモデル化を行う時の書き振りを近しく再現(中身は変更)しているため、わかりづらいかもしれませんが、”実務ではこうやっている” というのを理解していただければ。 先の要件を整理すると、数という概念に金額とポイントという2つのドメインモデルが含まれる。 金額とポイントという異なる概念を計算して最終的に獲得ポイント数を導き出す必要がある。 存在する制約 金額が負の数になることはありえない。ポイントが負の数になることはありえない。金額は日本円のみを考慮し、外貨は存在しない。ポイントは文脈によって呼び名が変わるが、単位は変わらない。支払い金額合計以上にポイント利用数が設定されることはない。金額に小数点は存在しない。ポイント
今回はアプリケーションアーキテクチャを学ぶ最初の一歩として、「MVC」や「3 層アーキテクチャ」などの基本的な用語の意味や関係性を整理する「改めて整理するアプリケーション設計の基本」。ここで大嶋氏が登壇。続いて、Controllerにプレゼンテーション層からデータアクセス層の処理をすべて記載している場合の分離方法について紹介します。前回はこちらから。 質疑応答 ドメインモデルパターンはドメイン騒動設計と同義か？ 大嶋勇樹氏：ということで、ここまでビジネスロジックの実装について話してきました。ここからは最後のステップとして、「Controllerに全部書く」からどうやってステップアップするかを話していこうと思います。 ここまでで質問があれば、ぜひQ&Aにもらえれば回答します。せっかくなので、このタイミングで「ドメインモデルパターンはドメイン駆動設計と同義ですか？」（という質問）に回答しておこ
Re: ドメイン固有型(値オブジェクト含む)を再考する - Software Transactional Memo
blog.j5ik2o.me 値オブジェクトはドメイン固有型の一種です。なので、不変と等価判定だけではなく、なにかしらのドメイン固有の不変条件(invariant)を維持する責任があると考えます(もちろん型として切り出すわけですからその投資に見合うだけの見返りがないといけません)。 違う。値オブジェクトとはID以外で等価判定をするオブジェクトの事であって、RubyのHash、Pythonのdict、C++のstd::unordered_setすらも値によって等価判定を行うのでこれらは値オブジェクトであるがドメイン固有型ではない。RubyでHashに入れて渡されたユーザ入力値をValidationしてドメイン固有型に詰め直すのはもちろん必要ならやれば良いが、Hashクラスそのものにモンキーパッチなり特異クラスなりを行って不変条件を維持する責任を負った自分専用Hashを作って普通のHashクラ
この記事は 弁護士ドットコム Advent Calendar 2020 19日目の記事です。12月19日の午前2時を過ぎて苛立ちがドアを叩くころです。 今年は上野学さんの単著『オブジェクト指向UIデザイン 使いやすいソフトウェアの原理』が発売され、OOUIという言葉が盛り上がっていますね。昨日のアドベントカレンダーの記事を書いた @shirauix さんともOOUIの話で盛り上がり、彼が主催で社内読書会も行われました。 さて、世間的にも社内的にもOOUIが盛り上がって読書会も開催されるなか、わたしは社内でひっそりと「タスクベースUI」の勉強会をやったのでした。 タスクベースUI？ 「タスクベースUI」という言葉は、先程の上野さんが盛んに言及することで最近有名になった言葉な気がします。 『オブジェクト指向UIデザイン』から引用します。 GUIのようにオブジェクトを起点として設計された操作モデ
ピュアなドメインを支える技術/pure domain model and the technology behind it
Presented at ScalaMatsuri2019 https://2019.scalamatsuri.org
2-3. 使用技術 アプリケーション作成 Java 17.0.2 Spring Boot 3.0.3 Spring Security 6.0.5 JOOQ 3.17.8（ORマッパー） データベース MySQL 8.0.32 UI HTML(Thymeleaf) CSS(Bootstrap 5.0.2) JavaScript(Chart.js 4.3.0) インフラ Fly.io (https://fly.io/) PlanetScale (https://planetscale.com/) 3. 実装するにあたって意識したこと 実務未経験者が初めて作成するアプリなので、何も考えずに作るとコードが無秩序な状態に陥ってしまうのではないかと思い、何かしら方針を決めたいと考えました。以前、書籍『現場で役立つシステム設計の原則』を読んだ際に、保守や変更に強いソフトウェアを作るための設計思想に「ドメ
こんにちは、ヘンリーの Lead Architect の @kohii です。 弊社ではレセコン一体型クラウド電子カルテの Henry を開発・提供しています。 最近 Henry のバックエンドをモノレポ化したので、その戦略やプロセスについて書きたいと思います。 こちらは前編となっており、モノレポ移行の手法やテクニックの話は後編で説明します。 dev.henry.jp Why モノレポ？ ざっくり説明すると、既存のマイクロサービス/チームの分界点を抜本的に見直し、ドメイン（業務の領域）による分割を目指すため、一旦モノレポにまとめて、理想的な構造の切り出しをやりやすくするという目的です。 モノレポ化前のシステム/チームアーキテクチャ バックエンド Henryのバックエンドはマイクロサービスになっていますが、以下の2つのサービスが大部分を占めています。 henry-general-api …
Rust で DDD を実践しながら API サーバーを実装・構築した（つもり） - Qiita
Rust 勉強中の身ですので、何かしら作ってみようと思い立ち、 API サーバーを構築してみました。 自力で一から公開できるサーバーを構築したのは初めてでしたので、試行錯誤の過程を記事にします。 作ったもの 何の変哲もない API サーバーです。 成果物は こちら にアップしました。 API サーバー Rust で実装 Web フレームワーク（Actor）: actix-web ORM: Diesel Docker イメージにして Heroku で稼働させる DB サーバー PostgreSQL を利用する Heroku PostgreSQL で稼働させる 開発方針 上記のインフラ構成を目標として、以下の開発方針を軸として調査や検証を行いました。 ローカルでの開発とサーバーへのデプロイはスムーズにできるようにする。 ローカルでテストや動作確認がスムーズにできるようにする：Docker の利
はじめに コンテナ技術の進展に伴って、ビジネス環境の変化に迅速に対応できるマイクロサービスに関心が集まっています。最近では、マイクロサービスを分割する方法の一つとしてドメイン駆動設計が注目されています。ドメイン駆動設計では、業務に精通した方々や技術者が、モデリングなどいろいろな技法や専門用語を使い、それらを理解した上で設計を進めていきます。様々なステークホルダーとチームを組んで一緒に取り組むにしても、直観的にはとてもわかりづらいと感じています。そこで、いろいろと記事を調べてみたり、身近な技術者と意見交換をしたところ、イベントストーミングという手法がありました。イベントストーミングに関する記事は他の記事に比べあまり多くはないので、この場で共有しておきたいと思い掲載することにしました。これからドメイン駆動設計をはじめるという方や、既に取り組んでいるけれど進め方に悩んでいる方など、参考になれば幸
DDDのエンティティはイミュータブルな実装にしてもいいの？(サンプルコード有り)[ドメイン駆動設計 / DDD] - little hands' lab
本記事はドメイン駆動設計（ＤＤＤ） Advent Calendar 2021の13日目の記事です。 エンティティとイミュータブル性 オブジェクトをイミュータブル、つまり内部状態を変えない実装にすることで可読性やマルチスレッド対応性が向上することがあります。 エンティティはモデリング上の定義はミュータブルなものですが、実装方法をイミュータブルにすることは可能です。 (DDDでは、エンティティはミュータブルもしくはイミュータブル、値オブジェクトは必ずイミュータブルという定義です。詳しくはこちら) DDD基礎解説：Entity、ValueObjectってなんなんだ - little hands' lab 本記事ではエンティティをイミュータブルな実装にするサンプルコードと合わせて、イミュータブルにした場合の旨みを感じられるコードを紹介します。 イミュータブルなエンティティ実装の例 エンティティをイ
![DDDのエンティティはイミュータブルな実装にしてもいいの？(サンプルコード有り)[ドメイン駆動設計 / DDD] - little hands' lab](https://cdn-ak-scissors.b.st-hatena.com/image/square/2b44a04ab53f865fdbd22ebaaedd541c0abb3877/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fl%2Flittle_hands%2F20211213%2F20211213073035.png)
This post took a lot longer to pull together than I expected. Not because it was hard to write, but because it was too easy to write too much. Like a pre-bonsai tree, it would grow out of control and get pruned back over and over. In the meantime, I delivered a workshop and spent some lovely holiday time with my family. But it’s a new year now, and January is devoid of holidays so it’s high time I
はじめに 前篇の「リアクティブマイクロサービス入門（1/2）- 概念編」では、なぜリアクティブマイクロサービスが必要なのか、リアクティブマイクロサービスとは何なのかをご紹介しました。 後編となるこの記事では、リアクティブマイクロサービスの実装するために使えるテクニック・技術を、目的別にご紹介します。 もちろん、これらすべてを盛り込まなければリアクティブマイクロサービスを実現できないわけではありませんが、引き出しとして知っておけばより柔軟な設計ができるのではないかと思います。 目的別にまとめているので、適宜リファレンス的にご参照いただければと思います。 モジュール化 リアクティブマイクロサービスに求められる性質をバランス良く満たすためには、ビジネス上の関心事を分割することが重要です。 トレードオフで同時に実現することが難しい要件でも、分割することでそれぞれの関心時に最適化した手段を選択して実
わかりやすくて最高だった「ドメイン駆動設計入門 ボトムアップでわかる！ドメイン駆動設計の基本」レビュー | DevelopersIO
わかりやすくて最高だった「ドメイン駆動設計入門 ボトムアップでわかる！ドメイン駆動設計の基本」レビュー 「ドメイン駆動設計入門 ボトムアップでわかる！ドメイン駆動設計の基本」を読んだところ、とても良かったのでレビューしたいと思います。 私の状況 まずこの本を読む前の私がどの程度ドメイン駆動設計について理解していたかご紹介します。 以前同僚が書いてくれたサンプルコードを手本にレイヤードアーキテクチャみたいなTypeScriptのLambda関数を書いている 「Service」とか「Repository」とかの単語を命名に使っているが、使い方あってるのか自信ない、というか意味をよくわかっていない 実装中「この構成でええんか？」と何度も思い悩む 時間かかるくらいなら雑にさっさと書いてしまったほうが良いのでは、と思うこともある。けどちゃんとしたコードを書きたいんや。 こういうのを読んで、テストしや
吉祥寺pm#19 での LT 資料です。
この記事は 株式会社ログラス Productチーム Advent Calendar 2023 の17日目の記事です https://qiita.com/advent-calendar/2023/loglassこんにちは。ログラスでエンジニアをしております、南部です。 ログラスでは、当アドベントカレンダーの5日目の記事で紹介されていますように、「DDDもスクラムも当たり前」な開発組織が形成されています。 私は、今年の9月からログラスに入社していますので、上記の記事で紹介されているログラスのDNAを受け継ぐ側に当たるかと思います。 そしてちょうど直近で、DDDの文脈においてこのDNAの価値を感じる機会がありました。 実は、前職でもDDDっぽいコードを取り入れたりはしていたのですが、それによって特にメリットは得られておらず悩んでいました。 結論、原因は私の不勉強でDDDの価値を出せる条件となって
なぜ自分はDDDを勉強しているのか？
DDDと出会う前 自分は元々アーリーステージ(シード)のスタートアップでRailsを書いていました。人手の問題で拙いながらもReact Nativeでモバイルアプリを作ったりAWSでインフラを構築したりとよくいるエンジニアです。昨年末に今の会社への転職がきっかけでDDDでの開発に従事するようになり独学でキャッチアップしました。元々DDDという単語自体は聞いたことがありました。きっかけは確かこちらの記事だったと思います。 ドメイン駆動設計の比類なきパワーでRailsレガシーコードなど大爆殺したるわあああ！！！ 自分自身Railsを書いてはいましたが、自分のコードに納得感を得られたことは一度もありませんでした。 このロジックはここに書いて良いのだろうか？ DB設計ってこれで合ってるのか？ う〜ん、テストコード書きにくいなあ よくある悩みです。しかし、スタートアップでスピード開発を優先していたの
オブジェクト指向プログラミング入門 -- Java object-oriented programming primer
Javaで学ぶ、オブジェクト指向プログラミングの基礎知識。型とカプセル化が腹落ちすると、びっくりするくらいオブジェクト指向プログラミングがわかようになる／できるようになるRead less
19/07/24開催の「持続可能なプロダクト開発への取り組み ～メドピアとクラウドワークスの事例公開～」における、クラウドワークス側の登壇資料です。 https://connpass.com/event/136791/
鬼滅の概念モデリング - Qiita
はじめに 概念モデリングとは、システムのドメインを構成する概念を発見しその属性・振る舞い・関連を定義する活動である。例えば、段階的に理解する O/R マッピングで実例として挙げたシンプルな課題管理システムにはプロジェクト・課題・コメントの 3 概念が登場するが、これらを概念モデルとして表すと以下のようになる。 本来、概念モデリングは DDD の主要な活動の一つである。DDD の Whirlpool プロセスの図を見てみよう。Model は Code Probe と Scenario に挟まれた中心概念であり、常時フィードバックを受けて更新されることが想定されている。 にもかかわらず、日本での DDD 関連の議論においては、概念モデリングが語られることは少なく、レイヤ分割やクラス類型といったアーキテクチャ的側面への偏りが見られる。パターンカタログを眺めればわかる通り、それらの要素は DDD
はじめに リアクティブシステムを構築するためのライブラリ「Akka」を開発する Lightbend社 から、リアクティブシステムやマイクロサービスについて学習できる有償のオンライントレーニング「Lightbend Academy」を提供されていますが、2020年夏の間（※）は無償で受講できるようになっています。 ※2020/07/14現在。当初は無償期間が6月末まででしたが、7月末 -> 夏いっぱいと期間が延長されています。 ※「Lightbend Academy」の受講については、こちらのスライド「Lightbend Academyオンライントレーニングを受けてみた」もご参照ください。 この記事では「Lightbend Academy」を受講して学んだ、リアクティブな性質を備えたマイクロサービスを設計・開発するために知っておきたい知識や理論 を、私なりに整理・再編してご紹介したいと思いま
合同勉強会 in 大都会岡山 -2020 Winter Online https://gbdaitokai.connpass.com/event/189232/ --- 開発者が事業活動に関心を持ち、ビジネスルールに基づく計算・判断ロジック（ビジネスロジック）を軸にアプリケーションを組み立てる、「CCSR」というソフトウェア開発手法をご紹介します。 参考: 要件定義・仕様化・実装の継ぎ目をなくすCCSR開発手法 https://masuda220.hatenablog.com/entry/2020/05/27/103750
こんにちは。株式会社InnoScouter CTOの大西(Twitter: @monarisa_masa)です。 InnoScouterでは、Ruby製WebフレームワークであるHanamiを採用しており、DDDを用いて開発しています。 Hanamiについて言うと、私個人としては、前職も含めて4年ほど運用経験があります。 ここでは、Hanamiが出てくるとよく話題にされるRailsとの比較は取り扱いませんが、初めてHanamiについての記事を読まれる方にも分かるようなサンプルコードで説明したいと思います。 突然ですが、こちらが本日のメイントピックです。 今回は、「RubyでDDDやるならHanami」と言われてますが、本当にそうなの？ってところを掘り下げていきたいと思います。 ツイートが意味していることと、それに対する自分の考えを話していけたらと思います。 この記事の対象読者 Rubyを触
PHPカンファレンス2019での登壇資料。 書き起こし https://note.com/tenjuu99/n/n0232ccd1089d あとがき https://note.com/tenjuu99/n/nbbb4b273676d メインの話の骨格は、MVC発案者であるトリグヴェ・リーンスカウク氏の2003年のJavaのカンファレンスでの資料(The Model-View-Controller (MVC) Its Past and Present)が元になっています。 http://folk.uio.no/trygver/2003/javazone-jaoo/MVC_pattern.pdf トリグヴェ・リーンスカウク氏は、この資料のなかでドメインサービス(業務システム)と個人の業務の関係を考えます。ドメインサービスと個人の業務にはギャップがあり、そのギャップを埋めるためにMVCは考えられ
はじめに TechTrainでエンジニアをしているスーです。 Twitterはこちらで、DMなど気軽にしてもらって大丈夫です！ 今回はTechTrainバックエンドの開発環境を紹介します。 開発全体について気になるのであれば、TechTrain技術スタック紹介と作り手としての市場に思うことを見ていただけますと嬉しいです！ バックエンドの開発環境前提 以前紹介した際からバージョンをしっかり上げました。 現在は、Laravel:9.x (PHP:8.1.x)を利用しています。 現状はDocker, Docker Compose, ECSを利用しています。 環境構築 Makefileを使いながら、M1 MacもIntelMacもコマンド一発で環境構築が終わるようにしています。 ここが結構メンテナンスが難しいところではありますが、常に更新を行なっています。 一発で立ち上がるところはこだわりの一つで
今の現場で初めてDDDに触れたので、よく採用されるアーキテクチャとしてレイヤードアーキテクチャを自分で0から実装してみました。 言語もよくセットで採用されているGoを採用してみました。 この記事の目的 0から実装して体系的にDDDとレイヤードアーキテクチャを学ぶ DDDに触れたことがない方にもわかりやすく説明する そもそもDDD(ドメイン駆動設計)とは 要約(引用)すると「ドメインの知識に焦点を当てた設計手法」です。 たとえば電子カルテのシステムを例に取ってみます。 電子カルテには患者情報や手術の予定、入院ベッドの空き具合などの概念があると考えられます。 医療関係者ではないソフトウェアエンジニアは実際につかうユーザー（医療関係者）が直面している問題やドメイン(領域)の概念、事象を理解することが必要です。 それらを理解し、ソフトウェアに落とし込む。落とし込み続けることを実践する開発手法です
先日、 という記事を書いたところ、思ったよりも反響がありました。その影響があったかは不明ですが、また値オブジェクトについての話題がちょびちょびと発生していました。 そのやり取りの中で、私は未読だった論文が紹介されていて、その論文を読んだことで「このようにすると値オブジェクトに誤解が生じる」という一つのストーリーを認知できたため、どのようにこの論文を読むと誤解が発生するか、という事について説明します。 なお、前回書いた記事も、この記事も、誤りを糾弾したいとか、誤ったから著者が悪であるといった事を主張しているわけではありませんので、改めて記しておきます。この記事では、単純に事実の指摘と修正の提案、およびなぜ文脈や定義を大事にする必要があるのかという事について述べます。 いい加減、値オブジェクトの話題はしつこすぎるのでは？非生産的なのでは？そんな事よりもっと生産的な事をしたら？というご意見もある
この記事はログラスDevチームAdvent Calenderの5日目の記事です。 SaaS開発のスタートアップ組織がスケールするためにこんにちは、株式会社ログラスの松岡(@little_hand_s)です。 ログラスは経営管理のSaaSを開発しているスタートアップ企業で、これまでアジャイル開発の手法としてDDD(ドメイン駆動設計)、スクラム、エクストリームプログラミングなどのプラクティスを適用しながら開発を行ってきました。 しかし、組織の規模が大きくなってきた(社員数が50人を超え、エンジニアチームも1チームから複数に分割されました)ことにより、それまでのスキルだけでは解消できない組織面の課題が生まれてきました。 そこで、今年の春から海外のアジャイルコミュニティで多く取り入れられている「システムコーチング®」という組織向けのコーチング手法を導入し、大きな手応えを感じているので、この記事では
はじめに コードを書いていると、途中で「このモジュールなんか長くなってきたな・・・どうしよ」「この処理ってここのモジュールに書くべきなんだっけ」等と設計的な悩みが発生することが結構あります。 チームで開発しているので、そういう場合には途中でSlackやビデオチャットで相談したり、コードレビューの段階でやりとりして解決していました。 そこで、ふと「いつも的確なコメントくれるなぁ」と思っていたメンバーがいたので、話を聞いてみると「ドメイン駆動設計」を参考にしているとのことで、読んだ本を教えてもらいました。それが「ドメイン駆動設計 モデリング/実装ガイド」でした。 読んでみると最初の悩みがかなりスッキリしたので、私と同じような悩みを持っている方向けにブログを書くことにしました。 本の簡単な概要 初めてDDD（以下、ドメイン駆動設計）を学ぶ方や、実際に着手して「難しい」と感じているエンジニアを対象
【登壇レポート】「ドメイン駆動設計を導入するためにやったこと」に、弊社エンジニア・ミノ駆動が登壇しました！ - READYFOR Tech Blog
こんにちは、READYFOR Tech Blog編集チーム・西和田です。 2022年1月17日（月）に開催されたイベント、「ドメイン駆動設計を導入するためにやったこと」 に、READYFORのバックエンドエンジニア、仙塲（ミノ駆動 @MinoDriven）が登壇しました！本記事では発表内容とご視聴いただいた方のコメントをアーカイブとしてまとめています。当日お聞きになれなかった方、また改めて見返したい方は是非御覧ください。 登壇者について ミノ駆動 @MinoDriven エンジニアリング本部 システム基盤部 バックエンドエンジニア 仙塲 大也（ミノ駆動） READYFORに2021年4月に入社 仙塲のSNSその他のブログは以下となります。 Twitter：ミノ駆動 @MinoDriven Tech Blog：リファクタリング効果を促進する組織ビジョン「乳化」 発表内容について 大きくなりす
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ドメイン駆動設計で貧乏を爆殺する - Qiita
CQSとCQRSの違いはメソッドの分離かモデルの分離かという観点 - Qiita
アクターモデルとアプリケーションアーキテクチャの関係 - nkty blog
DDDに関する論の主戦軸を整理してみた（2020年版） - Qiita
CQRS/ESによって集約の境界定義を見直す - かとじゅんの技術日誌
RDRA, ICONIX, DDDの実践から得た学び
Value Object (値オブジェクト) でリファクタリングしたら結構良かった
「クラスごとの役割を明確化すること」がポイント アプリケーション設計におけるドメインロジックの分離法
タスクベースUIとCQRS - Qiita
ドメイン駆動設計を参考にしながらJava×SpringBootで家計管理アプリを自作 - Qiita
医療スタートアップのバックエンドをモノレポ化した話 〜戦略・プロセス編〜 - 株式会社ヘンリー エンジニアブログ
これならできる！ドメイン駆動設計に役立つイベントストーミング - Qiita
Services By Lifecycle - Wide Awake Developers
リアクティブマイクロサービス入門（2/2）- 実現編 - Qiita
モデルとは何であって、何でないのか #kichijojipm
「DDDもスクラムも当たり前」な開発者組織に入って気付かされたDDDの価値を出すための条件｜南部豪
クラウドワークス プロダクトの持続的開発のためのリファクタリング実践アプローチ
リアクティブマイクロサービス入門（1/2）- 概念編 - Qiita
ビジネスルールを軸とした ソフトウェア開発手法 「CCSR」
「RubyでDDDやるならHanami」という噂の真相
MVCとはなにか/What MVC is
DDDのアーキテクチャを含むTechTrainバックエンド開発環境などを紹介していく！
DDDを意識しながらレイヤードアーキテクチャとGoでAPIサーバーを構築する - Qiita
値オブジェクトへの誤解が生まれる一つのストーリー - 文脈と定義を大事にする
スタートアップ開発 「DDDの次の一手」としてのチームコーチング｜little_hand_s
【書評】ドメイン駆動設計 モデリング/実装ガイド | DevelopersIO