ソフトウェア設計の原則には、リスコフの置換原則のほかに４つあり、まとめてSOLID原則と呼ばれています。
https://xtech.nikkei.com/atcl/nxt/column/18/02319/010500002/
わかりやすいですが途中から有料。
https://www.membersedge.co.jp/blog/typescript-solid-single-responsibility-principle/
およびそのリンクは無料。
S 単一責任の原則 Single responsibility principle
O 開放閉鎖の原則 Open/closed principle
L リスコフの置換原則 Liskov substitution principle
I インターフェース分離の原則 Interface segregation principle
D 依存性逆転の原則 Dependency inversion principle
上手くまとめる人がいるものですね。わかりやすくなるように、会社の従業員と製品に例えてみましょうか。
S 社員一人は一つの業務だけに責任をもつべきで、複数の業務が必要な時は人を分けるべし。
O 業務を追加するときに既存の業務を変更しないでよいように設計すべし。
L 上司が部下の業務を完全に行えるよう（置換できるように）に業務を設計すべし。言い換えると、部下は上司の知らない業務を行ってはいけないということです。親の決まりを子が破ってはいけない、と書かれるときもあります。
I 情報を受け渡すとき、不要な情報は分離するべし。これはスパイ小説に出てくる「右手の知ることを左手に知らせてはならない」に通じるものがありますね。ここでは分離していないと、不要な情報を担当する部分が変更されたときに、いらない修正が必要になることを嫌っています。
D 技術シーズに依存して製品を作ってはいけない。製品ニーズから仕様書を作って、開発者は仕様書に依存して開発すべし。（確かに依存性が逆転しています） 「仕様書」に対応するものをソフトウェア工学では「インターフェース」と呼ぶようです。「技術」「開発」はソフトウェアでは「関数」「機能」に対応します。
ソフトウェアがわかっている人には笑われてしまうかもしれませんが、それほど変な解釈ではないと思います。これは今考えたオリジナルのたとえです（当然同じことを考えた人はいると思いますが）。授業するときに使ってみます。
SOLID原則の目的は、保守しやすい、工数のかからない、不具合が発生しにくいソフトウェアを作ることです。会社のたとえでは、そのような効果はあるでしょうか？
たとえ話 allegory, parable, apologue, fable, similitudes
allegory 「ア」れゴリ 寓話 level 11
parable 「パ」ラブる たとえ（話）、比喩 level 9 Jesus taught in parables. イエスはたとえ話で教えた。
apologue 「ア」ポろグ 教訓寓話 level なし
fable フェイブる 寓話、説話、作りごと level 6 Aesop’s Fables イソップ物語 形容詞 fabulous ファビュらス
similitudes スィ「ミ」りテュード 類似、相似 level 22
segregation 別々に沈殿するような現象に使います。integration 統合の逆。 人の場合は、人種や宗教の違う人たちが一つの町で別々に住んでいるようすを表すときに使います。
工数(こうすう） man-day, man-hour ソフトウェア業界では日本語でも「人月（にんげつ）」「人日（にんにち）」という工数の単位がよく出てきます。
https://dime.jp/genre/1486539/
不具合 shortcomings, defect, flaw, fault ソフトウェアでは bug と言いますね。