DDD くらいできるようになりたいよねって話 - Qiita
はじめに 私自身は今年の 7 月にドメイン駆動設計（DDD）を実践する企業に転職したばかりで DDD 実践歴は浅いのだが、最近は開発業務の他にも中途採用者の DDD 教育や 現場で DDD！2nd のドライバー役をする機会を頂くなど、DDD の布教活動にも少し関わっている。 その中で「DDD ムズイ」という言葉をよく聞いたので、DDD の実践に悩んでいる人向けにサンプル問題の解説を通して、実は DDD 自体は難しくないんだよってことを教える目的で本記事を書いた。 TL;DR（最初に結論） DDD 自体はドメインを中心にモデリングと実装をイテレーティブに繰り返す設計プロセスであり、モデリングと OOP の理解があれば誰でもできる。 難しいのは DDD 自体ではなくて、モデリングまたは OOP である。特に「良いモデル」を得ることは非常に難しい。 なので「DDD ムズイ」と感じる人はモデリング
Value Object は不変にする | システム設計日記
ドメイン駆動設計(DDD)の Value Objects パターンでは、オブジェクトを不変(immutable)にすることを強く推奨している。 なんとなく、そんなもんか、と思っていたけど、ある日、なるほど、というケースに出くわした話し。 変数名にこだわる 前提として、変数名にこだわるようになったことがある。 DDD のユビキタス言語パターンの実践として、 ・パッケージ名 ・クラス名 ・メソッド名 ・変数名 は、業務上の意味のある名前にこだわることを、徹底しはじめた。 Java Calendar クラスの日付計算 当日から、２週間後に、期限切れになる、というビジネスルルールを実装していた。 Calendar getExpireDate() { Calendar now = Calendar.getInstance(); now.add( Calendar.DATE, 7*2 ); retur
実践DDDのサンプルプロジェクトが学びしかない - Mitsuyuki.Shiiba
IDDDを読んで、それなりに書いてあることは分かり始めたかな。と思ってたけど。 いざサンプルプロジェクトを読んでみたら、全然そんなことなかった。(ﾉД`)ｼｸｼｸ github.com いつものように、自分メモ。 プロジェクトの構成 全部で3プロジェクトと1ライブラリがある。 iddd_agilepm データストアとしてKVS(LevelDB)を使用。 DIコンテナは使ってない。 iddd_collaboration Event Sourcing と CQRS。ORM使わずにやってみた。 例をシンプルにするために、Event Sourcedな書き込みモデルと、CQRSの読み込みモデルを1スレッドで実行してる。イベントジャーナルとしてLevelDBを、リードモデル用にMySQLを使ってるのでほんのちょっとだけ一貫性がない状態が発生する可能性がある。別々のデータストアを使って、でも、できるだけ
DDD、CQRS(+ES)まわりの実装、参考ページまとめ | DevelopersIO
はじめに 弊社で開発するモバイルバックエンドのサーバサイドAPIアプリケーションコード (Play framework + Scala) はビジネスロジックを担う主要なパッケージである services, domains が外部のインフラやAPIインターフェイスに直接依存しないようなパッケージ構成をとっています。（Clean Architecture） services, domains の構成についてはDDDの経験が浅く、まだまだ改善の余地があると考えており、今後どうしていくか考えていくにあたって参考になるであろうページをまとめてみました。 尚、DDDまわりにおける筆者の現在の知識はドメイン駆動設計の第二部までを読み終わり、第三部を読み始めた程度です。 DDDと関連のあるCQRS+ES（Command and Query Responsibility Segregation + Even
混乱しがちなサービスという概念について - かとじゅんの技術日誌
社内でサービスがよくわからないという話になったので、考察を少しまとめておきます。 過去のエントリでも以下のように触れましたが、もう少しかみ砕いてみよう。 サービスという言葉はあいまい まず、簡単に前提の整理から。単に"サービス"って言葉が何を指すのか結構曖昧です。 サービスは簡単にいうと手続きとか振る舞いのことですが、細かくいうと、PofEAAでいうサービスと、DDDいうサービスは、目的が異なります。前者はアプリケーションのためにドメインモデルを再利用可能にするためのものです。後者はドメインの知識を表している振る舞いです。これはのちほど詳しく説明します。 まぁこのあたりは具体例がないと理解しがたいですが、レイヤーの違いによって責務が異なるという感じです。DDDのサービスの章では、サービスには、アプリケーション層、ドメイン層、インフラストラクチャ層と、複数のレイヤーに存在すると言及されていま
Scalaコードでわかった気になるDDD | GREE Engineering
みなさん、こんにちは。グリーのかとじゅん(@j5ik2o)です。 このエントリは GREE Advent Calendar 2013 の 18日目の記事です。よろしくお願いします。 私がグリーに入社してやっていることは、プログラミング言語 Scalaとドメイン駆動設計(以下、DDD)の布教活動です。布教活動といっても宣伝するだけでは具体性に欠けるので、実際に開発チームに入ってScalaやDDDの技術支援を行っています。本エントリでは、Scalaを用いたDDDの設計と実装をどのように行っているかを、DDDを知らない人でもできるだけわかりやすく説明したいと思います(Scalaわかっていると読みやすいですが、あんまり複雑なコードは出てこないのでなんとなく読めるのではないかと思います)。なお、DDDの実践例は他にもあります。一例だと思って読んでいただければ幸いです(先日のSNSチームでのドメイン駆
増田 亨
顧客に、役に立つソフトウェアシステムを提供する 著書： 現場で役立つシステム設計 ～変更を楽で安全にするオブジェクト指向の実践技法 技術： ドメイン駆動設計(DDD) , ICONIX , RDRA, Java / Spring domain-driven design object-oriented object-oriented programming ddd devlove ドメイン駆動設計 genbadeddd agile software development bpstudy java xp extreme programming dddesign オブジェクト指向 ooc_a ooc_2020 ccc_a2 jjug_ccc devlovex legacycode2019 microservices mixleap spring boot soi soe sor spring
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
