アラタナエンジニアブログ

aratana Engineer's Blog

学習する設計

この記事はaratana Advent Calendar 2017 - Qiita 15日目の記事です。

f:id:kimesawa:20171130110645g:plain
aratana advent calendar 2017


こんばんは。夜の鬼の洗濯板。きめさわです。

さて、ん〜、現場でやっているドメイン駆動設計の話しをしようと思ったのですが、実際のところ、何を書こうか。

そもそも皆さんどのように設計をしていますか?

エクセルやワード、パワポに画面を貼って、線を引っ張って、このボタンを押すとどうなるとかの処理を書くとかでしょうか?

DB設計だけして、テーブルと同じクラスを使って、MVCフレームワークを駆使して実装していくとかでしょうか?

それとも画面と同じクラスを作って、DB設計はRailsActiveRecordとかにお任せとかでしょうか?

そもそも設計などせず、とにかくソースコードを書いていく・・・でしょうか?

システムの設計について、こんな悩みはありませんか?

  • 1つの変更に対して、複数の画面が関わるので、同じ修正を複数のクラスや画面にもしなくてはいけなくなる(しかも、それが何画面あるのかわからず不安)
  • 1つのクラスが何百行、ときには万を超えるソースコードになり、簡単な修正もその修正箇所を当てるのにとても時間がかかる
  • 思いがけないデグレが発生する
  • Controllerに画面に関わる処理とビジネス上の処理、さらにDBアクセス等が混ざって肥大化している。
  • あとからリファクタリングしてきれいにしようと納期優先でソースを書くが、結局リファクタリングされない。
  • SQLのWhere句やストアドにビジネスロジックが入り込んで、簡単な修正なのに、DB側の修正が必要となる(ソースコードの修正だけで済まない)
  • 簡単な画面の修正なのに、htmlにif文、for文が入り組んでいて修正箇所が特定できない
  • 自動単体テストを書くことの有用性は理解してるが、対象のクラス・メソッドがでかすぎて何を書いていいのかわからない
  • 設計の資料が多すぎてどこに何があるのかわからなくなる
  • K/VストアからRDBに変更したいが、いろいろな箇所にストアへのアクセス処理が書いてあって全部拾いきれない
  • 同じ意味なのに、違う変数名があちこちに書いてある。
  • 残業が続いて今日のスターウォーズ上映初日に間に合わない

ドメイン駆動設計は上記のお悩みを解決するための方法を提示します。

画面からドメイン(ビジネスの問題領域)へ注力の仕方を変え、モデル駆動設計を採用することで、一つの修正に多くの箇所をいじることがなくなります。

一つのクラスは一つの責務しかもたなくなるので、ソースが短くなり見通しがよくなります。テストも書きやすくなります。

ビジネスロジックSQLやストアド・htmlのなかではなく、モデルに移行するので、ViewやDBアクセスと分離することができ、技術的なツールの移行も楽になります。

ユビキタス言語により、同じ意味なのに複数の言葉が出てくることはなくなります。そしてその言葉はステークホルダ間共通の言語になるので、会話もしやすくなる。

そして、うまくいけば、今日のスターウォーズの上映に間に合うかもしれません。

ドメイン駆動設計とは何か

ドメイン駆動設計とは、簡単に言えば、オブジェクト指向におけるモデリングと設計・実装について、コミュニティが実践・経験してきたものをまとめたパターン集」です。

なので、ちょっとやり方を調べただけでできるようなものではないし、特にオブジェクト指向というパラダイムについてきちんと学ぶ必要があります。

これまでの設計手法と違い、モデルを成長させていくことに意味がある手法ですので、アジャイル開発にピッタリの手法でもあります。


設計の仕方を学習すること

これまでの設計(上記のエクセルやパワポでの設計など)ってどのように身につけましたか?

元々チームの資産として、テンプレートが用意されていたり、全く無の状態からなんとなく作ってみたりとかそんなところではないでしょうか?
JavaRubyソースコードの書き方やフレームワークの学習は一生懸命するのに、肝心な設計の学習をしないのはやはりもったいない。

ドメイン駆動設計は会社のチームのような浅い歴史でできたものではなく、世界中のオブジェクトコミュニティが長い時間をかけて積み上げてきた手法です。

まずは学んでみませんか?

ドメイン駆動設計はビジネスの問題領域を学習する手法

ただし、ドメイン駆動設計を学んでも即素晴らしいソースコードが書けるわけではありません。

設計をしながら、ドメインの問題領域(作っているソフトウェアが解決するべき問題、対象の領域)について、学びながらモデルを成長させていくのが前提となっています。

学ぶのは開発者だけではありません。ソフトウェアを使う側も設計を通して、開発者と会話をしながら学んで行くというのがドメイン駆動設計の特徴の一つでもあります。

ドメイン駆動設計の勉強会をやります
ということで、来年になりますが、ドメイン駆動設計を導入したい!という方のために一緒にドメイン駆動設計を学ぶ勉強会を定期的に開催しようと思っています。宮崎でですが、、、

設計や実装にお悩みのみなさん、ぜひお待ちしています。

告知や募集は南九州ソフトウェア設計Labo - connpass、のほうで行う予定ですのでチェックお願い致します。

明日は同じ歳、同じ山部(って先週も書いたかも) @JotarO_Oyanagi 先輩によるVue.js Tokyo v-meetup #6 レポートの話題です。Vue祭りだ!ワッショイ!