こんにちは、株式会社TRYANGLEです。
前回に引き続き、10月の帰社日でも日本のDDD（ドメイン駆動設計）の第一人者として知られる
株式会社ログラスの松岡 幸一郎さんを講師にお招きして【第二回ドメイン駆動設計研修】を開催しました✨
今回の研修は【第二回目】ということで、
第一回目の研修で作成した開発中アプリケーションのモデリングしたものを基に実際のコードに落とし込んでいく内容で、 採用するアーキテクチャから各レイヤー毎の実装方法や様々なケースへの対応方法についても講義していただきました。
前回同様、DDDについて全く知らない社員から実際に利用し開発を行っている社員まで幅広い立場の社員に向けて行われ、
社員からは様々な感想が届きました。
今回も参加した社員の感想を抜粋してご紹介します！
① 参加する前にDDDについて悩んでいたこと
・DDDの概念を漠然と理解しており、具体的な実装の判断ができなかった。
・ユースケース層とドメイン層の切り分けや、DDDのデメリット、適用が難しい場合について疑問があった。
・モデリングを意識していたが、他者に共有する方法に悩んでいた。用語の意味や使い方を具体的に理解していなかった。
・実装への落とし込みに悩んでいた。
② 研修に参加して何を得ることが出来たか
・要件定義が主な設計思想だったが、詳細設計やコーディングにも活かせる場面が多いと感じた。
・コード実演で、ドメインを実体化するプロセスを理解することができた。
・Entityに処理を書けることが衝撃だった。また、リポジトリの結合はユースケースで行えばよいということがわかった。この処理はこの層でこのようにするといったある程度の予測ができるようになり、同時にオニオンアーキテクチャの理解が進んだ。
・「ルールや制約」はドメイン層、「仕様」はユースケース層に書くべきという明確な線引きを理解した。集約による余分なデータが増える場合は集約せず実装すべきだと学んだ。基本的に中長期的な保守を前提とした設計であるため、短期的な利用ではDDDは非効率になる場合があることも学んだ。
・ApplicationとDomainの違い、集約による冗長データの対応方法についての悩みが解決した。
・レイヤードアーキテクチャとドメインルールを適用したコードの実装方法を学んだ。集約の決め方が自分の中で曖昧だったが、リポジトリ単位で集約を決める方法が参考になった。
・ドメイン層の実装は素直にドメインモデル図から進めるとスムーズに行うことができるとわかった。モデル図の重要性を前回に引き続き再認識した。
・アプリケーション層（サービス）の役割が曖昧だったが、ユースケースに基づいて処理を定義する考え方がとても理解しやすかった。
・ドメイン層とアプリケーション層の役割を明確にできた。
③ 今後の業務で、実践してみたい・意識してみたい事
・自作予定のJavaアプリに今回の知識を活かしたい。
・初めてDDDを実践した際はクラス分けが手間に感じたが、機能改修や修正のしやすさを実感した。改めてドメイン駆動設計を意識した実装を心掛けたいと感じた。
・新規開発では集約の方法を意識したいと感じた。
・他メンバーへの業務ドメイン共有に今回学んだ進行方法を活用し、業務効率を上げたい。
・「層の役割」を意識した設計を今後の開発でも意識したい。イメージが掴めてきたので現在の開発にも取り入れたい。
・ユースケース層とドメイン層の分け方が曖昧だったが、今後は「ルールや制約」「仕様」を意識した設計・実装を進められるようにしたい。
・集約範囲を決める際、エンティティ間の繋がりのほか、集約が大きくなり過ぎないことに注意したい。
次回はラストとなる第三回目の様子をご紹介します。
TRYANGEでは各種研修を社内で定期的に実施し、普段の業務だけでは学びきれない知識獲得のフォローを行っています。
プログラマ・エンジニアともに大募集中！ですので、
一緒に学んでいきたい方はぜひHP上部メニューより採用サイトを覗いてみてくださいね🎵
最近のコメント