タグ

dddに関するkk42のブックマーク (14)

  • ドメイン駆動設計入門【DDDをわかりやすく解説】 | 楽水

    突然ですが、エンジニアの皆さま、Javaで開発したWebアプリケーションの構成、このようになっていませんか? データとgetter/setterだけのオブジェクト(JavaBean) 画面のコントロールやビジネスロジックの処理はServletが行う データベースのアクセスは、DAO(Data Access Object)に任せる もしそうであれば、そのシステム、ドメインモデル貧血症に陥ってます。 これは、データとgetter/setterだけのオブジェクトを、Anemic(貧血症になって元気がない)オブジェクトと称し、オブジェクトとはいうものの実質的にはデータであり、それをやりとりするだけの手続き型システムなっていることを嘆いたものです。 今回は、来のオブジェクト指向に立ち返り、そのメリットである高い保守性、再利用性、拡張性を備えた変化に強いシステムを作るための設計方法、ドメイン駆動設計

  • ScalaのEffを使ってDDDのUseCase層をいい感じに書いてみる

    *Qiitaに掲載していたものと同じ内容をこちらに移転しました(作者は同じです)。 今回のサンプルコードはyu-croco/ddd_on_scalaに掲載していますので、気になる方は覗いてみてください。 経緯 Scala(PlayFramework) x DDDでアプリケーションを実装する際、UseCase層(Application層)を実装する際に辛さが出てくる。 何が辛いかと言うと、型のネストである。 というのも、 UseCase層ではエンティティ操作の過程で仕様周りのバリデーションをやることになりEitherが出てくる 例:ハンターがモンスターから素材を剥ぎ取るためには、モンスターが既に死んでいる必要がある (PlayFrameworkだと特に)Repository層での呼び出してFutureが出てくる そのため、UseCase層での各処理の型合わせが必然的に複雑になる傾向にある。

    ScalaのEffを使ってDDDのUseCase層をいい感じに書いてみる
  • 100日間かけてエヴァンス本を完読しました(PDF公開) - そこに仁義はあるのか(仮)

    11/25から3/4の100日間かけてエリック・エヴァンスのドメイン駆動設計を完読しました! ソフトウェア開発の複雑さに立ち向かうための方法に「ドメイン駆動設計」があります。 エリック・エヴァンスのドメイン駆動設計(以降、エヴァンス)は発売から20年・日語訳発売から10年経っても読まれていて、ドメイン駆動設計の原著であり、多くのエンジニアが名著という一冊です。 その分厚さや内容が難しそうというイメージからずっと積んだままになっていている人も多いのではないでしょうか。 エリック・エヴァンスのドメイン駆動設計 作者:Eric Evans翔泳社Amazon 私もそんな一人で、ドメイン駆動設計をなんとなく知った風に過ごしていましたが、ドメイン駆動設計に関する勉強会への参加をきっかけにエヴァンスと向き合い、知ったこと・学んだことを毎日1ページにまとめてツイートする活動を始めました。 100日間

    100日間かけてエヴァンス本を完読しました(PDF公開) - そこに仁義はあるのか(仮)
    kk42
    kk42 2022/03/11
  • 最近の海外DDDセミナーを聞いてみたら色々と常識が破壊された - Qiita

    TL;DR 最近の設計志向はイベント駆動がかなり中心になっている とくにDDD界隈がここまでイベント駆動一槍だとは思わなかった ストーリーを出発点にイベント駆動で設計を組み立てる「イベントストーミング」がかなり多くの場所で事例として取り上げられている はじめに 最近、洋書や動画の講演資料などいくつか海外の情報源に当たることがおおくなり、その中で「結構日でやられている取り組みとちがうなー」と考えることが多く、一旦そのあたりの差分をまとめておこうかと思いました。 ただの出羽守(あるいは鹿鳴館精神)ではなく、一つの潮流としてこんなのがあるってのを記述できればなと思います イベントが設計の基線となりつつある、、、のか? まず1つ目に驚いたのが、イベントが設計の中心になっている、そう感じる機会が多かったこと。 ここで言うイベントは、実践ドメイン駆動設計の中でも「ドメインイベント」として実装パタ

    最近の海外DDDセミナーを聞いてみたら色々と常識が破壊された - Qiita
    kk42
    kk42 2022/03/01
  • 「集約の境界と整合性(略」に対して頂いたアイデアの分類と現状での僕の回答らしきもの - kbigwheelのプログラミング・ソフトウェア技術系ブログ

    解決策1 集約をマージするタイプのアイデア 解決策2 一時的な整合性の破綻を受け入れ結果整合性を使うタイプのアイデア A. 組織へ無効状態で追加後、有効化するアイデア A.i 連続的に追加・有効化を行うアイデア A.ii 追加後、有効化を別スレッドやイベント駆動で行うアイデア B. 組織に所属するユーザー一覧というドメインオブジェクトをアイデア B.i ユーザー一覧を組織集約に持たせるアイデア B.ii ユーザー一覧を独立した集約にするアイデア C. イベント駆動アーキテクチャの長期プロセス(サーガ)的なアイデア D. オーバーがNGなら逆に現在ユーザー数を先に増やすアイデア 解決策3 アンチパターンではあるが集約間の整合性維持のためトランザクション制御を用いる 解決策4 ユースケースの見直しによる再モデリングタイプのアイデア 僕の現時点での回答らしきもの 現時点での回答: 解決策2 B.

    「集約の境界と整合性(略」に対して頂いたアイデアの分類と現状での僕の回答らしきもの - kbigwheelのプログラミング・ソフトウェア技術系ブログ
    kk42
    kk42 2022/02/09
  • 安全で柔軟なAlways-Valid Domain Modelの作り方

    はじめに 昨今ではますます Immutable な Domain Model の有用性が認知されているように思います。 また、Domain Model が持つ制約(不変条件)を満たさないインスタンスを作れないようにする事の重要性も広く知られてきており、Always-Valid Domain Model といった名称もついているようです。 ここでは、制約を満たしたDomain Model (Always-Valid Domain Model) しか作成できないようにするファクトリメソッドについて、より柔軟で合成可能性の高いファクトリメソッドを定義する方法を紹介します。 この記事で利用する言語とライブラリのバージョンは以下の通りです。 Scala 3.1.0 cats-core 2.7.0 最初のエラーで全体を失敗とするファクトリメソッド まずは単純に Either を使ったファクトリメソッド

    安全で柔軟なAlways-Valid Domain Modelの作り方
  • Domain Modeling Made Functional

    About This Title Pages: 310 Published: January 2018 ISBN: 9781680502541 In Print Domain Modeling Made Functional Tackle Software Complexity with Domain-Driven Design and F# by Scott Wlaschin You want increased customer satisfaction, faster development cycles, and less wasted work. Domain-driven design (DDD) combined with functional programming is the innovative combo that will get you there. In th

    Domain Modeling Made Functional
  • ボトムアップドメイン駆動設計

    はじめに この記事は前後編に分かれています。 順序だてた解説になっているので最後までお付き合いいただけると幸いです。 後編記事: https://nrslib.com/bottomup-ddd-2/ 順序立っての説明になっておりますので、前編からご覧になることを強くお勧めします。 セミナー情報 こちらの内容のセミナーを不定期で開催しています。 ◆セミナーページ 第一回: https://ddd-community-jp.connpass.com/event/103428/ 第二回: https://ddd-community-jp.connpass.com/event/107106/ 第三回: https://nrs-seminar.connpass.com/event/117283/ ◆あとがき 第一回ボトムアップドメイン駆動設計勉強会を開催しました セミナースライド まえがき この章は

    ボトムアップドメイン駆動設計
  • ドメイン駆動 + オニオンアーキテクチャ概略[DDD] - little hands' lab

    DDD連載記事 なぜDDD初心者はググリ出してすぐに心がくじけてしまうのか ドメイン駆動設計の定義についてEric Evansはなんと言っているのか モデルでドメイン知識を表現するとは何か ドメイン駆動設計で実装を始めるのに一番とっつきやすいアーキテクチャは何か 背景 ドメイン駆動設計で実装を始めるのに一番とっつきやすいアーキテクチャは何かの記事で、オススメしていたのはオニオンアーキテクチャでした。 今回は、オニオンアーキテクチャについて詳しく説明したいと思います。 上述の記事でも書いた通り、「ヘキサゴナル、オニオン、クリーン」の3つは、質的には全く同じで、思想としてはヘキサゴナルで完成されているのですが、より具体的に説明されているオニオンアーキテクチャから説明を読んだ方が理解がしやすいと思います。 その後にヘキサゴナルの説明を読むと「なるほど」となって「あれ、結局ヘキサゴナルじゃん」と

    ドメイン駆動 + オニオンアーキテクチャ概略[DDD] - little hands' lab
  • モデルでドメイン知識を表現するとは何か[DDD] - little hands' lab

    DDD連載記事 なぜDDD初心者はググリ出してすぐに心がくじけてしまうのか ドメイン駆動設計の定義についてEric Evansはなんと言っているのか モデルでドメイン知識を表現するとは何か ドメイン駆動設計で実装を始めるのに一番とっつきやすいアーキテクチャは何か ドメイン駆動 + オニオンアーキテクチャ概略 概要 DDDの定義についてEric Evansはなんと言っているのか この記事でドメイン駆動開発の定義は以下のようなものであると書きました。 ドメインの中核となる複雑さと機会に焦点を当てる ドメイン専門家とソフトウェア専門家のコラボレーションでモデルを探求する 明示的にそれらのモデルを表現するソフトウェアを書く 境界付けられたコンテキストの中のユビキタス言語で話す では、ドメインの知識を言語化したモデルは、最終的にコードでどのように表現されるのでしょうか? 不変条件 まず、業務の制約に

    モデルでドメイン知識を表現するとは何か[DDD] - little hands' lab
    kk42
    kk42 2018/03/18
  • Introduction to the practice Reactive-DDD

    AWS データベースブログの記事 「Amazon DynamoDBによる CQRSイベントストアの構築」 を勝手に読み解く

    Introduction to the practice Reactive-DDD
    kk42
    kk42 2018/03/18
  • Vaughn Vernon氏が語る、アクターモデルとドメイン駆動設計

    Spring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。このでは、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...

    Vaughn Vernon氏が語る、アクターモデルとドメイン駆動設計
  • Reactive DDD with Scala and Akka | Skills Matter Meetup

  • Eric Evans氏: ドメイン駆動設計はソフトウェア開発に有益か?

    Spring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。このでは、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...

    Eric Evans氏: ドメイン駆動設計はソフトウェア開発に有益か?
    kk42
    kk42 2016/07/31
  • 1