はじめに 過去２回のパッケージ構成について vermeer.hatenablog.jp vermeer.hatenablog.jp 約3年ぶりに改めて考察してみようかと。 DDD関連に影響は受けていると思いますが別物です。 ３層＋ドメイン を基本とした構成です。 なぜ改めて見直すのか？ React…

最近、仕事場で 「DDDって分かります？」 と聞かれて、うーん と思いながら 「仕組み（アーキテクト）と、設計デザイン（思想）の両面があって、仕組みの話はクリーンアーキテクチャのそれに類似だと思います。設計の方はユースケース駆動みたいなフローでは…

vermeer.hatenablog.jp を元に アクターとユースケース（権限）の実装をしてみました。 まだサービスやコントローラーへの適用はしていません。 想定する要件 アクターが複数あって、それぞれに権限がありそうなものということで「申請フロー」を題材にしま…

vermeer.hatenablog.jp 上記ではDomainやFormでの検証結果については、Pageクラスで指定した順序でメッセージ出力する事が出来ました。 ですが、Application層以降の検証不正については、レイヤーを跨った関連付けをする仕組みを持たないと その順序性を管理…

最新の考察 vermeer.hatenablog.jp はじめに vermeer.hatenablog.jp で ベースを考えて 以下の参考プロジェクトを コツコツと肉付けしています。 vermeer.hatenablog.jp 新しい機能を実装する中で段々と どのパッケージに どのクラスを配置させるのが良いの…

vermeer.hatenablog.jp の流れで、Application層のServiceを実装することにしました。 また、Serviceの事前条件不正などをクライアントで どうやって出力するのか という検討の準備でもあります。 Serviceの基本的な あり方については 以下の記事で以前 整理…

vermeer.hatenablog.jp から、多少の肉付けをした版。 やったこと Validation ValidationExceptionの制御 メッセージ（出力まで） ConversationScope制御 Redirectの強制 基本は過去の記事などで取り扱った要素を組み込んだ感じです。 DDD的なところ？ あん…

vermeer.hatenablog.jp 以前の記事では、どちらかというと Presenter パターンに近いイメージで実装しています。*1 集合の部品となるForm その主たる関心事であるドメイン（ValueObject）を包含します。 インスタンス化およびgetterの際の型は基本的にString…

Formに関して色々と考えている中で、部分的に考えるのも良いけれど、一度、ベタで自分なりにJava EE（JSF）で、DDDっぽい感じの実装サンプルをつくってみて もうちょっと全体を見渡せるようなものを作ってみた方が、もう少し具体的に考察出来るのかなぁと思…

Formに関して、アレコレ考えていると、Entityとの類似点が多いように思えてきた。 つらつらと思いついたことをメモ。 Identification 画面のどこの何、という意味で「ここのこのフィールド」という一意な場所が必要。 姓と名が同じ値だった場合（そんな名前…

vermeer.hatenablog.jp の続きです。 AnnotationでLabelを付与するという仕組みにしたわけですが、よくよく考えてみるとFormObjectというインターフェースをもっているのだから、そこで対象クラスを判断してPropertyに登録した表示項目名を参照するようにし…

はじめに 標準のBeanValidationで宣言的に実装する というのをするのは良いのですが、表示させるメッセージとしては「どの項目」というラベルが欲しいところです。 messageに項目名を付与した文言を都度指定する、というやり方もあると思いますが、テンプレ…

前回はコードのイメージということで全量を公開していませんでした。 vermeer.hatenablog.jp 今回は、前回はしていない部分のコードの説明を中心にしていきたいと思います。 Form用のValidation関連 マーカーとなるアノテーションと優先度を示すアノテーショ…

vermeer.hatenablog.jp で書けなかったモヤモヤしたところを、自分なりにBeanValidationを中心として考えていく中で整理できつつあるので、具体的な実装に入る前に、まず まとめてみたいと思います。 それは、画面用オブジェクト（以降、Form）とドメインオ…

はじめに BeanValidationのメッセージを遅延変換する、ということの意図を簡単に説明したいと思います。 BeanValidationは検証（validate）した際にメッセージ変換も一緒に実行してくれます。 基本的に、これはありがたい機能なのですが、Domainで発行したメ…

最新の考察 vermeer.hatenablog.jp レイヤーで論理的な役割を整理したので、次はパッケージです。 パッケージ概要 フォルダ構成例 boundedcontext ├─application │ └─service │ └─hoge │ ├─domain │ ├─model │ │ └─hoge │ │ hogeFactory │ │ hogeRepository …

オレオレDDDを一から整理し直し。 まずは、レイヤーから。 レイヤー構成 Presentation 外部インターフェース（外部向け定義および操作）に関する機能を実装する層 「外部に対する表現」が主たる役割 Application ドメインを用いて機能を実現する層 判断／加…

要件定義からテスト設計までの流れで個人的に思うところのメモ（２） 自分の経験の整理 vermeer.hatenablog.jp の続き いきなりモデリングはやめよう （また？） 理由 モデリングのような抽象度の高いことよりも、個別具体のところから整理していった方がユ…

要件定義からテスト設計までの流れで個人的に思うところのメモ 自分の経験の整理 いきなりモデリングは止めよう 理由 モデリングをしていると、仕事をやった気持ちになるけれど 実現してほしいことに近づいているか？というと そもそも近づくべき目的を共有…

RDRA モデルベース要件定義 at BPStudy from Zenji Kanzaki www.slideshare.net speakerdeck.com ドメインモデルの根拠とドメインモデル貧血症の対策について - Chatwork Creator's Note DDD Alliance! RDRA流概念モデル - connpass の資料（資料への直接リ…

ddd-alliance.connpass.com 書評も書かせていただいた「現場で役立つシステム設計の原則 」の著者である増田さん（@masuda220 ‏）の本には書けなかったこと、というのを聞いてきました。 2017/08/30(水) DDD Alliance! 現場で役立つシステム設計の原則 Night…

概念 原本のエッセンス [ 技術講座 ] Domain-Driven Designのエッセンス 第1回｜オブジェクトの広場 [ 技術講座 ] Domain-Driven Designのエッセンス 第2回｜オブジェクトの広場 [ 技術講座 ] Domain-Driven Designのエッセンス 第3回｜オブジェクトの広場 I…

★この記事は過去の検討内容です 再検討のまとめ vermeer.hatenablog.jp 以下は過去の検討メモです。 振り返りができるように残します。 現在、システムのリファクタリング中。 大きなシステムではないですし開発者も利用者も基本的に私一人です。 そんな中で…