ドメイン駆動設計を導入するために転職して最初の3ヶ月でやったこと[DDD] - little hands' lab
この記事は ドメイン駆動設計 Advent Calendarの記事です。 今年の9月にログラスというスタートアップに転職しました。 ログラスは元々DDDについて講師として勉強会をさせてもらっていた会社であり、DDD自体は社として取り組んでおりある程度進んでいました。ですが、講師ではなく中の人になったからこそできる色々な取り組みがあり、3ヶ月である程度形になりました。 本記事では、DDDを広めるための取り組みについて、極力再現性がある形を意識しつつ、ご紹介したいと思います。 入社時の状況 なにをしたか テストの話が多い理由 実施内容詳細 TDD Boot Campの@t_wadaさんの基調講演観賞会を行った Serviceクラスを1パブリックメソッドにした レイヤーごとのオブジェクトの依存関係を整理 レイヤーごとのテスト方針 クラス名の重要性 参照実装を作成した 「責務」と「テスト」の重要性
![ドメイン駆動設計を導入するために転職して最初の3ヶ月でやったこと[DDD] - little hands' lab](https://cdn-ak-scissors.b.st-hatena.com/image/square/468995f3b9ed8114c64ac798322572db942591ca/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fl%2Flittle_hands%2F20201221%2F20201221103037.png)
ドメイン駆動設計に関する何か - 日々常々
2020-03-13追記: 「ドメイン駆動設計」のハードルを上げる意図はありません。そもそもそんな特殊技能でもないと思っています。「ドメイン駆動設計が合っているか」を測る材料になるかも？くらいの気持ちで読んでいただけると幸いです。 何度目か知りませんがDDDがまたブームを迎えているようで。DDD難民と言う言葉が出た頃を思うと感慨深いですね。実際難民になったわけではないので肌感覚で知らないのが残念なところですが、これはどうでもいい。 DDD、日本語ではドメイン駆動設計となりますが、DDDを冠していてもドメインが語られることは少ないようです。 数ある書籍もドメインモデリングの話ではなく、ドメインモデルをいかに実装に落とし込むかにフォーカスしていると感じています。 これはこれで仕方ないと言うか、ドメインの話って広く語れないんですよね。 ドメインは領域で境界があって範囲が限定されています。特定ドメ
効果的にDDDを導入するために気をつけるべきこと - Qiita
DDDはプロジェクトの期待に応えていますか？ この記事を読み始めたということは、あなたはDDDに興味を持っているか、またはDDDを実際に実践しているのでしょう。 最初に、あなたとDDDの関わり方について質問です。 あなたが実践しているDDDは、満足度の高いソフトウェアをユーザーに届けるのに、効果的に機能しているでしょうか？ またはこれからDDDを導入したいと考えているなら、どのようにDDDがあなたの問題を解決するか、イメージできているでしょうか？ どちらかにNoと答えたなら、この記事の内容が役に立つかもしれません。 DDDを学び始めるとき、我々エンジニアは技術的な面に興味が向きがちです。 レイヤードアーキテクチャ(基本だね!) クリーンアーキテクチャ(依存方向は内側だけに向くようにするんだ!) CQRSやイベントソーシングなどの手法(ストレージを分けるのか分けないのか...) モジュール分
ドメインモデルをコードへ落とす 〜あなたのクラスは、どこから？〜 - Qiita
annotation: 現在コメントいただいている通り、一部誤りを含んでいる様です。 追って確認・修正いたしますが、現行ではコメントも合わせてお読み頂ければと思います。 こんにちは、風邪はだいたい喉から来るぷーたんです。 「DDDの構成要素はこれだー」というのはたくさんあったのですが、 「このドメインオブジェクトはどの要素だー」と逆引きするものがなかったので調べてフローチャートにしてみました。 例えばドメインモデル図とコードがうまく合致しない時の見直しなどに使えるのではと考えています。 ではご覧ください♪ 検討フローチャート 図1.フローチャート 1) 複数のドメインオブジェクトを扱い、整合性を担保するか まず複数のドメインオブジェクトを扱うかを考えます。 ドメインモデル図では集約線が引かれていたり、複数の関係線が引かれていたりします。 図2.ドメインモデル図の例 上記のような場合であれば
なぜDDD初心者はググり出してすぐに心がくじけてしまうのか - Qiita
DDD連載記事 * なぜDDD初心者はググリ出してすぐに心がくじけてしまうのか * ドメイン駆動設計の定義についてEric Evansはなんと言っているのか * モデルでドメイン知識を表現するとは何か * ドメイン駆動設計で実装を始めるのに一番とっつきやすいアーキテクチャは何か * ドメイン駆動 + オニオンアーキテクチャ概略 背景 直近のプロジェクトでDDDの思想に則ったアーキテクチャで一つリリースまで漕ぎ付けまして、そこに至るまで色々と調べたり試行錯誤をしながら学んだことを書いていこうと思います。 一番にですね、大体のDDDに興味を持った人がいうのが ということなんですよね。 DDDは思想としてすごく面白く、とても実用性なものなのに、なんでこんなにわかりづらいのか、ハードルが高いのか！！ という点について、私なりの解釈を述べたいと思います。 心をくじく要因 Eric Evans本は説明
ToKyoto.jsでScala.jsについてLTしてきました。 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
自分の発表について speakerdeck.com もう3日前のことになりますが、ToKyoto.jsでLTしてきました。Scala.jsの話です。スライドにあるし、このブログでも何度か取り上げていますが Scala.js 普通に実用性あります。とはいえ「実用性がある」と「使うべき」の間には高い壁がそびえているわけですが……。 ちょっと補足的な話をしておくと、ReduxやVuexが提供する状態管理パターンのよさはいくつかあって、 Single source of truth が守られる 参照系と更新系が強制的に分離させられる 以上の二点により、プレゼンテーション上でのデータの分割構造とロジック上のデータの分割構造が分離される ヘッダーで使う情報とメインコンテンツで使う情報が互いに関連するみたいなやつが、おなじデータソース見るの簡単とかそういうこと 自分でデータの変更をobserveしなくて
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
ドメインモデルにおける集約ルートには、グローバル空間で一意なIDが必要？
ドメインモデル（ドメイン駆動設計）では、集約ルートにはグローバル空間で一意なIDを付けるべし、という情報を得ました。 DDD本にも、「（集約）ルートエンティティはグローバルな同一性を持つ」という記述があります。 ※ごめんなさい、電子書籍なのでページ番号分かりません。集約の不変条件についての記述です。 このことについて疑問がありますので教えて下さい。 例えば、プロジェクト管理アプリケーションを作っているとします。 ざっくりとした要件はこんな感じです。 プロジェクトを複数管理できる ひとつのプロジェクトは複数のタスクから構成される 人員を複数管理できる 人員は、色々なプロジェクトのタスクに割り振られる こうすると、集約としては「プロジェクト」と「人員」が出てくるかなと思います。 どちらも「プロジェクトID」と「人員ID」という、グローバル空間で一意なIDを付ければ良さそうです。 また、「タスク
DDD with RDRA, ICONIX
DDDを具体的なプロセスに落とし込むにはどういう観点が必要だろうか。 - 境界づけられたコンテキストがどこまでの範囲かよくわからない - ユビキタス言語やドメインモデルをどのように発見すればいいかわからない。どこから着手すればいいのか？ - ドメインモデルがただのデータの入れ物になってしまう(貧血症) という問いに答えるには、RDRA, ICONIXを検討するとよいというテーマの資料です。
無限のメモリ空間と絶対に落ちないプロセスを仮定して「ビジネスロジック」をあぶり出す - assertInstanceOf('Engineer', $a_suenami)
先日、前職の上司から「そろそろプロフィールに"詩人"を追加するべきだ」と言われました a-suenami です。今日も今日とて詩人業を行なっていきますよ！ 「ビジネスロジック」とは何か 最近、業務で、比較的中長期的なアーキテクチャの見直しだったり、新機能の設計だったりをさせてもらう機会が増えた。 コンポーネントをどういう風に分割するかとか、それぞれのコンポーネントを主にどのチームでメンテナンスしていくかとか、そういうのを考えるのは楽しい反面、かなり熟慮に熟慮を重ねないといけないものでもあるのでかなり責任を感じるというのもある。 まあ、そんなこんなでいろいろうーんうーんって悩んでいると昔（たぶん DDD コミュニティだと思うけど）誰かに言われた「無限のメモリ空間と絶対に落ちないプロセスがあったとして、それでもそのコードを書かないといけないのならそれがあなたのドメインだ」という言葉だ。 モデリ
DDDを使ってRailsアプリをリファクタリング - Qiita
経緯 casyというインターネットを使って手軽に家事代行を頼むことができるサービスのプログラマをしています。 Webだけでなく、スマホアプリも出すことにあたり、Webアプリサーバ(Rails)から機能を切り出し、APIサーバ(Rails)を別途作成し、Webアプリの場合はWebアプリサーバからAPIサーバを呼び出し、アプリからは直接APIサーバを呼び出すような仕組みにしました。 ただ、全部の機能をAPIサーバに移すのは容易なことではなかったため、いくつかの機能はまだWebアプリサーバに残っていて、アプリよりもWebのほうが機能が多い状態となっています。 今回残りの機能をAPIサーバに持ってくるにあたり、下記２つのアプローチがありました。 1. 既存のソースコードからViewを切り離してほぼそのまま持ってくる 2. 設計を見直し、大幅にリファクタする チーム内で議論した結果、スタートアップと
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ドメイン駆動設計のガイドライン: Capture - Embed - Protect
ドメイン駆動設計でマイクロサービス開発