「単価がどういった単位で決まるか」を知ることはビジネスのやり方そのものを深く知ることでもあります。たとえば、単価が商品コードだけでユニークに決まるビジネス。それは非常に単純なビジネスです。販売の方法に多様性がない、１回で売る数量がいつも予想の範囲におさまる、決済の方法は現金に限る、顧客の種類が少なく一様に扱える、など。しかし、ビジネスが多様化してくると事態は一変します。店頭販売とインターネット販売では別な単価、販売量ランクに応じたディスカウント単価、現金決済とカード決済では別な単価、一般店と量販店では別な単価、・・・・・。
単価が決まるエンティティが５つもある企業は、販売業務が成熟途中の企業です。当初、単価をもつエンティティは、商品エンティティ１つで充分だったものが、多様化の段階に応じてエンティティを１つずつ追加してきたのです。
さて、成熟段階がさらに進むとどうなるか。多様性がありすぎて、バリエーション別のＫＥＹを用意することが難しくなります。利用部門の見方で言えば、取引条件別の単価を一元的に管理する台帳がほしくなります。これがプライスリストです。
「意味の濃さと設計上のあそび」の日記でも言及しましたが、ＫＥＹを特定のリソースに限定すると意味が混じらない、純粋なエンティティを設計できます。その一方で、多くのバリエーションを表現できないといった欠点があります。
商品コードをＫＥＹとして管理される単価は、商品の属性という意味は明確ですが、商品以外の意味を追加することはできません。単価の種類が増え、［商品コード＋○○コード］−（単価）というエンティティを増やす方法にも限界があります。ビジネスが多様化するに従って、［プライス番号］−（単価）といった構造に変化するのです。
プライスリストは、単価に対して直接的にＫＥＹを設け、単価がきまる条件の多様性を吸収するパターンです。適用する際は、その企業における現時点のビジネスと多様化のスピードを考慮して使います。
