Spring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。この本では、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...
![関数型言語を使ったドメイン駆動設計](https://cdn-ak-scissors.b.st-hatena.com/image/square/ae84da8ad454d9f147ee9b8b3d04e38c76d6581b/height=288;version=1;width=512/https%3A%2F%2Fcdn.infoq.com%2Fstatics_s2_20240530133300%2Fstyles%2Fstatic%2Fimages%2Flogo%2Flogo-big.jpg)
ドメイン駆動設計というのはソフトウェア工学のおしゃれな本で,Kindleで買えたので読んだ.ドメインを軸に戦略的に設計しましょうという本.2週間くらいで読めて良い体験できてよかった. ソフトウェアを,ユーザーインタフェース,アプリケーション,ドメイン,インフラストラクチャという4つの層に分けて,一番重要なのがドメイン層で,ドメイン層にアプリケーションが存在し得る理由がある.銀行システムだったら,口座とか利子みたなやつがドメイン層で,口座がよくできてると銀行としてうまくいく.ATMのタッチパネルというのはユーザーインタフェースで,どんなにATM押しやすくても,ドメイン層に,口座という概念がなくて,ただのハッシュだったりすると,銀行を運営して金を儲けるとか,新たな金融商品とか作るのが困難になる.インフラ層は永続化とかするのだけど,インフラ層がいかによくても,意味ないデータを保存していては銀行倒
ドメイン・モデルと開発に注力しないと"太ったサービス・レイヤ"と"ドメイン・モデル貧血症"によるアプリケーション・アーキテクチャになってしまいます。この場合、ファサード・クラス(通常はステートレス・セッション・ビーン)にどんどんビジネス・ロジックが溜まっていき、ドメイン・オブジェクトがgetter/setterからなる単なるデータの運び屋のようになってしまいます。このアプローチをとるとドメイン固有のビジネス・ロジックやルールが複数の異なるファサード・クラスに散在(時には重複)することになります。 "ドメイン・モデル貧血症"はたいていの場合、コストに見合いません。他の企業と比較して利点があるわけではなく、このアーキテクチャの下でビジネス要求の変化を実装するには開発と本番環境へのデプロイするのに時間がかかり過ぎます。 DDD実装プロジェクトにおけるいろいろなアーキテクチャや設計について見ていく
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く