プログラムを書くとき、人と話をするとき使えそうな考え方をまとめています。
間違いが含まれていると思うので注意。

Module

何らかの機能を持った部品。
複雑な機能を作る場合、お互いに独立した部品を組み合わせて作ると、全体を制御しやすそう。

参考:

SICP

Information Hiding

複雑な機能をmoduleに分解するとき、変更が加わりそうな箇所を隠すように分解すること。いざ変更が加わることになっていても、その変更は隠されていて他の部品からは見えない。したがって変更する箇所がその部品のみになる。

例えば、ブログポストを永続化させる仕組みを考えてみます。永続化の手段は、インメモリ、ファイル、RDBMS、等あると思うので、永続化は変更が加わりそうな箇所でしょう。そこで、どのような手段を選んだかという設計上の決定を、ほかの部分から見えなくさせることが、Information Hidingだと思います。典型的なのは、Repositoryというインターフェースを切って、インメモリのRepository実装はInMemoryRepositoryImplにする、等でしょう。

永続化の手段は、永続化がどのくらい続くかという観点で見ることができます。インメモリでは、サーバーが再起動すると、保存したデータが失われる。一方、ファイルでは、サーバーが再起動しても失われない。要件が変わってインメモリからファイルになっても、同じmodule構成を維持できそうです。でも、今後の要件次第では、現在の設計では隠し切れないほどの意思決定がなされることがある可能性はあるとは思います。

参考:

On the Criteria To Be Used in Decomposing Systems into Modules

Abstract Data Type

抽象データ型。
Data abstraction (データ抽象) とも同義。

データの実現手段・表現方法を、そのデータを扱う部分から隠すこと。
例えば、有理数はその分子と分母を取得できる。有理数から分子と分母を取得する手段を提供し、有理数の表現 (consを使っている、クラスを使っている、等) は隠す。

たとえば、有理数とは分子と分母からなる数であって、consやクラスのインスタンスとは普通定義されません。有理数を扱うほかのプログラムはまさしく有理数を扱いたいのであって、consやクラスのインスタンスは扱わないはず。

おそらく、Information Hidingの一種。

参考:

SICP
Object-Oriented Software Construction

Single Responsibility Principle

単一責務の原則。

同じ理由で変更を受けるものを集め、違う理由で変更を受けるものは分離するという考え方。

たとえば、ブログポストを永続化するmoduleは、ブログポストの構成の変化と永続化手段の進化という二つの理由で変更を受けそうです。

参考:

https://blog.cleancoder.com/uncle-bob/2014/05/08/SingleReponsibilityPrinciple.html

ユースケース

システムとアクターのやりとりを記述したもの。
アクターは、そのシステムとやりとりすることのできる役割のこと。

同じユーザーでも時と場合によっては違うアクターになることもあると思っています。たとえば、同じユーザーであっても、稟議の申請者になることもあれば、承認者になることも。

参考:

TODO

Data Context Interaction (DCI):

ユースケースのアルゴリズムを、ユースケースに参加するRole同士の振る舞いで記述すること。

参考:

Lean Architecture for Agile Software Development