[B! DDD] Systemのブックマーク

Rust でも学べる関数型ドメイン駆動設計 - Domain Modeling Made Functional の読書感想文 - じゃあ、おうちで学べる

はじめになぜ 2026 年に、2018 年出版の本を再読するのでしょうか。正直に言えば、『Architecture Modernization』の翻訳作業で DDD の概念が頻出し、「分かったつもり」の理解では訳せなくなったからです。初読から 7 年。関数型の視点で DDD を説明する本書を、今度こそ腹落ちさせたかった。読む動機『Domain Modeling Made Functional』は、DDD と関数型プログラミングを組み合わせたアプローチを解説する書籍です。 Domain Modeling Made Functional: Tackle Software Complexity with Domain-Driven Design and F# (English Edition) 作者:Wlaschin, ScottPragmatic BookshelfAmazon 著者の

System 2026/01/23

リンク

ドメイン駆動設計の集約のわかりにくさの原因と集約を理解するためのヒント - ソフトウェア設計を考える

『ドメイン駆動設計』のモデル要素のひとつとして「集約」があります。アプリケーションの対象となる事業活動の仕組みや決め事をソフトウェアで表現する技法のひとつとして集約の考え方はとても役に立ちます。集約パターンはデータベースのデータ整合性の視点での説明されることが多いようです。しかしデータ整合性の文脈で集約を理解しても、ドメイン駆動設計の中核の関心事である「ドメインの複雑さ」を理解しドメインの知識をクラスで表現するためにはあまり役に立ちません。この記事では、集約パターンをドメインロジックを表現するモデルの構成要素として効果的に利用するためのヒントを提供したいと思います。集約はデータ操作の道具ではありません。集約はビジネスルールにもとづくドメインロジックのモデリングと実装の手段です。ここがわかるとドメイン駆動設計の理解が一気に進むと思います。どうして集約がデータ整合性の話になってしまう

System 2021/05/08

リンク

形から入ったドメイン駆動設計によるゲーム開発の光と闇

TECHxGAME COLLEGE #28(https://techxgamecollege.connpass.com/event/148035/) の発表資料です

System 2019/10/25

リンク

Domain-driven design in FP. For the last couple of years, I have… | by Naveen Negi | Geek Culture | Medium

Maybe you are convinced that domain driven design is the best way to tame complexities in software applications — even when those are written in functional languages. You have searched over internet looking for way to achieve it, but felt disappointed with dearth of resources. Even when you found one, It lacked true essence of functional programming, It lacked power of composition, It stubbornly a

System 2019/08/22

clojure
DDD

リンク

ドメインモデル中心のアーキテクチャ | GuildWorks Blog

System 2015/12/07

リンク

[ Android ] - これからの「設計」の話をしよう | リクルートテックブログ

はじめまして。 6/1より入社いたしましたAndroid エンジニアの釘宮です。よろしくお願いいたします。今日はAndroidの設計について語ってみようと思います。その前に「良い設計とはなにか」という議論が「正義とはなにか」という議論のようにいつまでたっても結論がでないのは、環境やチームメンバのスキルセット、ステークホルダーによって目指すべきゴールが変わるためだと考えます。つまるところ、設計に正解はありません。そのため以下で話すことは、「これが設計の正解だ！！」というわけではなくて、「こういう設計の仕方するとうまくいくっぽい」くらいのノリです。あと、特にMVCとかDDDとか人によって解釈のズレが起きやすいところなどは、冗長になるのを嫌って自分の解釈で言い切っています。ご了承ください。設計の目的についてハードルが下がったところで、早速。まず設計の目的ってなんでしょうか？この