以前、書いたように、ASP.NET Identityはクリーン・アーキテクチャ的な設計・実装になっているんですが、この度、それを放棄してしまいました。と言う話です（放棄すると言っても、大きな設計変更を行うと言う話ではなく、以降、リカバリをしないと言う事です）。

　...と言うのも、今、Storeの切り替えって、DIじゃなくて、UserStore内でMemory Store と RDBMS Storeは、IF文で分岐させているんですよね。コッチの方が実装し易いので（NoSQL Storeとか出てきたら、DIにしても良いかも知れないケド）。そう言うこともアリ、拡張のデータ・アクセスをDI無しの単純なライブラリで実装してしまい、これで不整合が発生し始めました。

　...と言うと、「じゃあ、その、拡張のデータ・アクセスも、DI対応させたら？」と言う話になるかも知れませんが、結局、モチベーションが無いですよね。だって、現時点で、NoSQL Storeに対応する予定は無いですモン（Hybrid-IdPの下段のIdP/STSをSTS専用モードで動作させて、LDAPなどの、ある意味NoSQLとパスワード認証だけ行うというケースはあります）。

　以前、Wikiにも書いたんですが、Apache NiFi の Controller → Processor（ProcessorのType → DataStore）を呼び出す部分を、クリーン・アーキテクチャ的に実装する。なんて言うのは、良いと思うんですよね（ある意味、ソレが、設計・実装の目標になり続け得るプロダクトだと思います）。しかし、全てのプロダクトに同じようなモチベーションが発生し得るか？と言うと、必ずしもそうではないよね？と言う話も多いかと思います（だいたい、データ・ストアに、何を使うか？なんて、ほとんどのプロダクトで固定されてるだろ。的な）。

　...で、ですね、モチベーションに左右されるようなものって、結局「ワーク」しないんですよね。というのも、先日、以下のようなツイートを目にしまして。


　ココでは、「抽象化」って言葉を使用していますが、モチベーションも同じで、「幅」があるんですよね。「幅」があるモノって、結局、人によって解釈がズレてくるから、労働集約的なスキームの中で、そのまま継続させて行くと、設計・実装が、上振れしないで、下振れ一辺倒になって、最終的に破綻するんだと思います。

　こう言う事を言うと、「リファクタリングがー。」みたいなことを言う人が現れそうな気がしますが、「イチイチ、リファクタリングしないとイケナイような、仕組みが既に稚拙で破綻している。」と言う事で、適合するか否かは、明確に、設計・実装の目標となるような「根拠」を最上流に持っているか？そして、それをKPI等に設定して、モチベーションに関連付けているか？否か？だと思います。

　...で、無能なケースと言うのは、最上流の部分に、このような根拠を持っていないのに、下流で、なんか、ゴチャゴチャ、無駄な事をしようとする、その戦略性の無さなんじゃないか？と思う次第であります。