DeNA TechCon 2018- Frontend:DDD - - DeNA Design
約1年間の構想と実装期間を経て、担当事業のKenCoMがリニューアルオープンしました。今回の発表には、その過程で向き合った課題・解決したテクニック、DDDの統合を盛り込んでいます。【公開資料】：サービス開発における フロントエンド・ドメイン駆動設計の実践 いま、フロントエンド・エンジニアには、SPAを筆頭にリッチクライアントと呼ぶに相応しい実装が求められています。私の担当事業に限った話ではなく、フロントエンドの状態管理（データバインディング技術・データフローアーキテクチャ）は、次のステージに移行している様に感じています。 従来バックエンドが抱えていた複雑さの取り扱いが、フロントエンドに移行してきているのは間違いないでしょう。DDDは言語不問のアプローチであり、プログラミングのためだけのもではありません。この一角をコードに反映させることで「アプリケーションが複雑に変化していっても破綻しない」
Almin.js がやってくれること - Qiita
この記事はQiita Advent Calendar 2017 React #1 の 4日目の記事です。 Almin.js について最近学んだことを説明します。 概要 今、業務で開発しているシステムで、Almin.js + TypeScript + React を使ってフロントエンドの処理を実装しています。 Almin.js Almin.jsの採用を検討したのは、フロントエンドでDDDに沿った設計をするのに使いたかったからです。 今回調査も兼ねて実装してみると、Almin.jsを利用することで、思っていたよりいい感じにクラスを設計できました。 その課程で Almin.js が何を提供するライブラリなのかということも理解が進んだので、学んだ内容を共有します。 必要だったもの 今回の開発にあたり、Viewを実装するためにReactを使うことは決まっていましたが、それ以外の部分についてはどうやっ
Where does Data import task/service fit in DDD?
I'm currently trying to build my first solution following DDD principles. Until recently everything was more or less clear, but now I have a task to import configuration data for my application and I am not sure what would be a best place to fit such a functionality... I have a sales analysis application, and at some moments there is a need to renew price list data (add new/delist products, or upd
Living Documentation by design, with Domain-Driven Designを読んだ
Living Documentation by design, with Domain-Driven Designを読んだ Living Documentation by design, with Domain-Driven Design by Cyrille Martraire [PDF/iPad/Kindle]という電子書籍を読んだ。 leanpubで$0から購入できて、任意の値段で購入できるドキュメンテーションとDDDについての書籍。 追記: 書籍版 Amazon.co.jp: Living Documentation: Continuous Knowledge Sharing by Design (English Edition) 電子書籍: Martraire, Cyrille: 洋書 ドキュメンテーションもソフトウェア開発のように設計やテストといったパターンやアプローチがありま
Functional and Reactive Domain Modeling 各章まとめ - Qiita
Functional and Reactive Domain Modelingとは、ドメイン駆動設計(DDD)の関数型プログラミング(FP)とリアクティブプログラミング(RP)によるアプローチを書いた本 1. 関数型ドメインモデリング：イントロダクション 変更可能なステートを避ける - 変更可能なステートは管理が難しく、非決定性につながる 参照透過性 - FPは、参照透過なモデルコンポーネントを設計する能力を提供する。モデルの振る舞いが純粋関数で構築されていることで合成性を得られ、小さな関数から大きな関数を作ることができる 自律的成長 - 関数型の設計と思考で、モデルは自律的に成長する。純粋性故にモデルは数学的に扱うことができ、推論ができる コアドメインに集中する - DDDの原則を使用してモデルを構築すると、リポジトリやファクトリといったパターンに基づいて編成されたエンティティや値オブジ
DDDに関する質問にバシバシお答えしました [ドメイン駆動設計] - little hands' lab
先日、メディアマックスジャパン様(以下、MMJ様)にお邪魔してドメイン駆動設計勉強会を開催してきました。そちらで質疑応答セッションがあり、実際にドメイン駆動設計で開発をしだしたタイミングで出てきた具体的な疑問について色々お答えしました。 おそらく多くの人が同じような疑問を持たれそうな内容だったので、MMJ様の許可を得てこちらでも紹介したいと思います。 コンテキストの分け方について DBを複数コンテキスト共通でつかっていいのか？ スキーマわけなくていいのか？ コンテキストごとにスキーマは最低限分けることをオススメしています。詳細は以下の記事をご参照ください。 little-hands.hatenablog.com 機能ごとに切る？ユーザ種別ごとにコンテキストわけるべきなのか？ コンテキストの切り方が正しいかどうか、どうやって判断すればいいか？ コンテキスト設計は、従えば作れるようなフローチャ
![DDDに関する質問にバシバシお答えしました [ドメイン駆動設計] - little hands' lab](https://cdn-ak-scissors.b.st-hatena.com/image/square/13f84b8758b38db7917b04405e41e71b2b5f7c43/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fl%2Flittle_hands%2F20171221%2F20171221134405.png)
境界づけられたコンテキスト 実装編 - ドメイン駆動設計用語解説 [DDD] - little hands' lab
little-hands.hatenablog.com こちらの記事で説明できなかった、「境界づけられたコンテキストをどうやって実装に落とし込むのか？という話を書きます。 境界づけられたコンテキスト実装の基本イメージ 結論からいくと、基本的には、 1コンテキスト = 1アプリケーション と思ってもらってOKです。 これを基本として、用途や実装コストと相談しながら少しずつ設計を組み替える検討が可能です。 1アプリケーション単位で、オニオンアーキテクチャ概略の記事で紹介したアーキテクチャを1セット揃えると思ってください。 つまり、こちらの記事で紹介した2つの境界づけられたコンテキストに対して、 以下のようにアプリケーションを2セット作ります。 ドメイン層を外界と隔離して、外部に公開するする操作を周りの層で定義するのです。 最終的に、マイクロサービス2つ作ると思ってもらって良いです。そうすると、
![境界づけられたコンテキスト 実装編 - ドメイン駆動設計用語解説 [DDD] - little hands' lab](https://cdn-ak-scissors.b.st-hatena.com/image/square/651dc2c9022ca618fd318e11235cd199205385a3/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fl%2Flittle_hands%2F20171207%2F20171207001225.png)
境界づけられたコンテキスト 概念編 - ドメイン駆動設計用語解説 [DDD] - little hands' lab
境界づけられたコンテキストとは 公式DDD Referenceの定義は以下の通りです。(和訳はだいぶ意訳しています) bounded context A description of a boundary (typically a subsystem, or the work of a particular team) within which a particular model is defined and applicable. 境界づけられたコンテキスト 特定のモデルを定義・適用する境界を明示的に示したもの。 代表的な境界の例は、サブシステムやチームなど。 まぁなかなかよくわからないですよね。DDD用語の中でもかなり難解なワードです。 境界づけられたコンテキストは、2つの観点から解説が必要でしょう。 ・概念としての境界づけられたコンテキスト ・境界づけられたコンテキストをどう実装に
![境界づけられたコンテキスト 概念編 - ドメイン駆動設計用語解説 [DDD] - little hands' lab](https://cdn-ak-scissors.b.st-hatena.com/image/square/6bb65ba88fd34a29140629a2f7085b6e005c2663/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fl%2Flittle_hands%2F20171128%2F20171128072027.png)
私的実践DDD、その１ - たなかこういちの開発ノート
ようやく「実践ドメイン駆動設計」を読み終わりました。 髙木正弘訳、ヴァーン・ヴァーノン著、「実践ドメイン駆動設計」 実際にありそうな開発プロジェクトのストーリーに沿うかたちで話が進められます。コードExampleが極めて具体的に示されて、どうすべきかが非常に分かりやすい参考書だと思いました。コードのExampleはJava、C#がメインでしたが、これのScala版（関数型言語版）があったら、これまたすごい参考書になりそうな予感がしました。 DDD（Domain Driven Design、ドメイン駆動設計）は、エンタープライズ・システムのアーキテクチャーに関するパターン集です。DDDが言うのは「パターン」ですので、DDDの用いる用語でそれを認識しておらずとも、DDDが言及するパターンを少なくとも部分的には適用している開発の現場は実は数多くあるはずなのです。私もその辺整理、確認したくて同書を
DDD - the rule that Entities can't access Repositories directly
There's a bit of a confusion here. Repositories access aggregate roots. Aggregate roots are entities. The reason for this is separation of concerns and good layering. This doesn't make sense on small projects, but if you're on a large team you want to say, "You access a product through the Product Repository. Product is an aggregate root for a collection of entities, including the ProductCatalog o
Domain-Driven Rails e-book + example app
Struggling with complex Rails app and business domain? Do you recognize these problems in your application: no clear boundaries, just one big monolith with hundreds of models and associations ActiveRecord classes are getting really big (50 attributes even) and constantly acquiring more knowledge about your whole system and more responsibilities service objects dealing with too many responsibilitie
実装 - Hexagonal Redux - - Qiita
Reduxのヘキサゴナルアーキテクチャ Reduxの様なイベント駆動アーキテクチャでDDDの恩恵を受けるため、ヘキサゴナルアーキテクチャを採用するモデリングの考察です。疎結合なドメインモデル同士は、時に外部ドメインで扱う横断的関心事を参照する必要が出てきます。 Redux は SingleStore のため、全部入りのエンタープライズモデルと捉えられがちですが、それを構成する Reducer と対の Model が、マルチドメインを構成する単体のドメインモデルだと捉えています。先日投稿したモジュールの構成で、ヘキサゴナルアーキテクチャを採用する準備は出来ています。用語のマッピングは以下の通りです。 DomainModel = immutable.Record DomainEvent = ReduxAction Port(in) = ReduxReducer Port(out) = Redu
QCon Tokyo 2011 アーキテクチャパネルディスカッション＋DDD雑多ネタ
アーキテクチャパネルディスカッションとラウンジ・ビアパーティでの雑談から、主にDDDに関して興味深かった話をいくつか。聞き取り能力は低いので抜けている部分もあると思いますがご容赦を。 ビジネス的な有用性はどこにあるのかEvans氏発言要旨 経営層など意思決定を行う人たちに対して、ドメイン駆動設計の有用性をどう訴えかけるのか？という問いに対して、Evans氏は主にコアドメインへの注力によって競争上の優位、市場優位につなげる部分を強調。ここから一段階細かいレベルとして、ビジネスパーソンにとって理解できるソフトウェアへと進んでいくとのこと。ただし、常に労力に見合う価値が得られるわけではないことも忘れずに付加。 雑感この質問はなかなか難しく、聴衆の反応も微妙なものだったように思う。これは、DDDをオブジェクト指向設計方法論として受け取っている人が多く、こうした部分の有用性についての回答を期待してい
#teppeis_sushi でクライアントサイドDDDについて発表した
#teppeis_sushiというイベントで、Faao - ドメイン駆動設計で作るGitHub Issue Client -という話をしました。 Electronやブラウザなどで動くfaaoというGitHubクライアントを書いていてそれの技術的な話です。 クライアントサイドでDDDを取り入れた設計になっていて、その設計や規約の作り方やそれを守る方法についての話をしました。 azu/faao: Faao is a GitHub issue/pull-request client on Electron. Living Documentation by design, with Domain-Driven Design by Cyrille Martraire [PDF/iPad/Kindle]という無料から買える書籍では、ドキュメントとコードを同じ速度で成長させていくためにはドキュメントに対
DDDにおけるIdentifier/Entity/Repository間の関係をScalaで型付けする - Qiita
2016/06/07 追記 下記の実装には問題点がある（gakuzzzzさんからコメントで指摘いただきました）ので、そちらも合わせてご参照ください。 はじめに DDDにおいては、ドメインの登場人物を取り扱うための、様々なデザインパターンが登場します。 典型的には、例えばユーザというエンティティを考えると ユーザは一意なIdentifier(ID)を持つ IDをリポジトリに渡すと、リポジトリはDB上のデータからユーザを生成する リポジトリはエンティティのライフサイクルにおける、永続化部分の隠蔽を担当します。関連する部分の雰囲気だけコードに表すと、こんな感じになるでしょうか。 class User(val id: Long) class UserRepositry { def resolve(id: Long): User = ??? //省略： DBアクセスしてUserを取得するコード }
実践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を使ってるのでほんのちょっとだけ一貫性がない状態が発生する可能性がある。別々のデータストアを使って、でも、できるだけ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Eric Evans氏: ドメイン駆動設計は、以前より以上に妥当性を獲得している
おれたちのスマホアプリとWeb版 / Real World React Native
#teppeis_sushi
普段使いのDDD
