システム開発で思うところ

JavaEEを主にシステム開発をしながら思うところをツラツラを綴る

DDDでリファクタリング後を検討してみる

現在、システムのリファクタリング中。

大きなシステムではないですし開発者も利用者も基本的に私一人です。

そんな中で、ああしたら良いかも、こうしたら良いかもと考えながらやっていたわけですが、闇雲にやるのは良くないなと。ということで、自分なりのゴールを一度整理しておいた方が良いだろうと思い、まとめてみました*1

 

なぜDDD?

システムの規模だけを考えたら無理をしてDDDじゃなくても問題はない気がしています。ただ、今後も拡張・メンテナンスをするシステムなのでDDDを取り入れるのが良さそうだと考え至りました。*2

 

どのように検討した?

先人の知恵を参考にしつつ、過去の経験を踏まえて分類・整理しました。

参考にさせていただいた知恵

 

全体図

前提・共通事項

レイヤー

要素

View

Domain

Infrastructure(Service)

Infrastructure(Common)

補足

 

[改訂版] UMLモデリング技能認定試験<入門レベル(L1)>問題集 -UML2.0対応

[改訂版] UMLモデリング技能認定試験<入門レベル(L1)>問題集 -UML2.0対応

 

 

エリック・エヴァンスのドメイン駆動設計

エリック・エヴァンスのドメイン駆動設計

 

 

実践ドメイン駆動設計

実践ドメイン駆動設計

 

 

検討メモ

2016/12/26:Ruleはstaticではなくクラスで(∵DI対象に拡張できるように)

 

2017/8/8:RepositoryはServiceではなくInfrastructure。

基盤=インフラという整理でビジネスに近いということでServiceと考えていたけれど調べてみると、Service(Domain)ではInterfaceを定義しておいて、Infrastructureで実装するということだった。こうしておくことでJPA依存からDomainを守ることが出来るという考え。

逆に基盤=インフラという整理の部分はレイヤーはInfrastructureで良いけれど、Commonとして別パッケージにしておいた方が、個人的にはシックリくるという整理にも至った。

 

 2017/8/10:トランザクションの境界はServiceではなくてRepository

DDDにおいて、なぜ複数の集約にまたがってトランザクションをかけてはいけないのか(multiple aggregates in one transaction) - pospomeのプログラミング日記

(整理資料の更新は未実施)

・データの整合性を保つのが誰の役割なのかに注目する
・それがユーザー自身であれば、トランザクション整合性を保つようにすればいい
・それが別のユーザーであれば、結果整合性を保つようにすればいい 

 

*1:スライド貼り付けなので、若干やっつけ感がありますが・・・

*2:とはいえ、DDDについてですが、きちんと分かっていないと思います。有名どころの書籍も読んだことはありません。UMLもかなり昔に勉強したなぁ、という感じです。