私のよく使うソフトウェアアーキテクチャの雛型

サンプルプロジェクト 構成 イベント駆動と CQRS を意識した、レイヤードアーキテクチャをベースとしたヘキサゴナルアーキテクチャになります。 各層について レイヤードアーキテクチャをベースに、以下の4層に分けています。 プレゼンテーション層: ソフトウェアの入出力を担当 アプリケーション層: ソフトウェアのユースケースを担当 ドメイン層: ドメイン知識を元にしたビジネスのルールや制約、プロセスを担当 インフラストラクチャー層: 技術的関心ごとの全般を担当 ディレクトリ構成 domain/ # ドメイン層 models/ ## ドメインモデルを格納 services/ ## ドメインサービスを格納 application/ # アプリケーション層 use-cases/ ## ユースケースインプットポートを格納 interactors/ ## コマンドにあたるユースケースの実装クラスを格納

[prograti]

自分はJavaだけどイベントソーシングを除いて似たような作りでやってますね。イベントソーシングは自分が関わる開発案件ではオーバーエンジニアリングなのでログ目的でイベントを永続化するだけかな

[crimson_diamond]

これだと、バグが起きた時に永遠に判明しないし、データの非同期な連携が重なれば重なるほどシステムは予測不能になっていくだろうから（あとパフォーマンスもね）、作ったら作りっぱなしの人なのだなと思った

[ss49919201]

CQRSの解像度かなり上がった。

[riri13]

、

[makuradohizato]

ネガティブなコメントは筆者の考えじゃなくて、一般的なCQRS/ESに対するものなので、CQRS/ESを採用する前提で考えればテンプレートとしては凄く良いと思います

[nemoba]

実践ドメインのIDDDもHQLで思いっきりDB中身触ってたり。そこに中身どころか永続化さえも不透明にするESはぶっちゃけカオス。でもDDDの終着点で教義どおり。プロジェクトの性質でトレードオフとらないと悲劇を生むがDDD

[ue-sho]

ブクマがネガティブになっているがかなり良いと思う

[xlc]

「何か凄そう」感だけは出ている。

[yuuu1993g]

アーキテクチャ界隈怖い

[atico]

クエリがドメイン層パスするとレイヤードアーキテクチャの意味がなくなり、ドメイン貧血症では？主ドメインを読みやすくするためのDDDなので、 イベントはサブドメインが使うためのものにしないとコードを追いにくい