ディスカッションをする大切さ

こんにちは、季節もすっかり秋になってきました。と思ったら急に暑くなったりと、体調管理が難しい気候だなと感じます。 引き続きデータモデリングの勉強をしているのですが、議論する重要さにいろいろ気づきました。 きっかけは一緒に勉強しているメンバーの子に楽々ERDレッスンという本を読んで、疑問をなげかけた時です。 「商品コードは主キーになりえないとのことなんだけど、どう思う？？自分は主キーになり得るかなと考えているだけど、なぜなら商品が同じでも新たな商品とみなして、insertを積み上げていけば良いと思っているだけど？？」 という投げかけに対して、「~のユースケースがあるから、自分は〜だと思う」という具合に議論が活発になり、モデルが洗礼されていくのを感じていました。 そして、商品という概念から、他のユースケースを考え、おのずと他のデータモデルの設計ができてきました。 一人で学習することは、確かに大切です。ですが、ディスカッションをすることでより洗礼する感覚があります。

下記は商品から派生して作成したテーブルです。(あくまでディスカッションしながら作成しているので完璧なものではないです。)

create table 商品(
  商品Id  interger primay key,
  商品コード varchar, 
  商品名    varchar,
  金額　　　　integer
  ...
)

create table 商品履歴(
  履歴Id
  商品Id  interger primay key,
  商品コード varchar, 
  商品名    varchar,
  ...
)

create table 税率(
  税率Id PK
  税率
)

create table 注文(
  注文Id  PK
  利用者Id FK
  合計金額
)

create table 注文詳細(
  詳細Id
  注文Id FK
  商品Id FK
  税率Id FK
  商品価格
)

create table 利用者 (
  利用者Id  FK
  支払い方法Id FK
  profileId FK
)

create table 支払い方法(
  支払い方法Id
)

create table 現金払い(
  現金払いId　PK
  支払い方法Id    FK
)

create table カード払い(
  カード払いId　PK
  支払い方法Id     FK
)

create table カード詳細(
  カード詳細Id
  カード払いId FK
  カード番号
  カードブランド
  支払い形式
)

そして、slerの頃にどいうテーブル設計をしてたかというと、依頼主からの仕様をもとにエンジニアだけで作成していまいした。 確かに仕様書どうりに満たせるテーブルになっていたと思います。ですが大切なのは開発者とドメインエキスパートとの対話で生まれるドメインモデルの洗礼。 ここが重要なんじゃないかなと考えます。 モデルを洗礼することで、隠れている概念を抽出する作業をすることで、data storeレベルでの複雑さの軽減につながるのではないかなと考えた今日この頃でした〜 最後は長々となってしまいましたが、それではバイバイ〜