どうしてスタートアップのソフトウェア設計はいつもいつもブッ壊れてるんですかぁ？
つまりどんなに優秀な人間をかき集めようがスタートアップのソフトウェア設計は近い将来壊れる宿命にあるということです。 普通のやつらの上を行け、ではありませんが。
スタートアップ企業はうまくいくかわからない事業をやることそのものに価値があります。 「誰からみてもうまくいくに決まってる」事業で金も人材も潤沢にある大企業と張り合うのは、少なくとも現代では難しいでしょう。
そして、ゆえにスタートアッププロダクトのコード設計は壊れます。これは構造的問題なのでカネで解決することは不可能です。
DDDを適用すべきじゃない、みたいなことを筆者が主張しているのもこれが原因です。 それともお前
何十年も修行して達人にでもなるのを待ってから戦場に出るつもりか？
気の長げェ話だな
みなさんは綺麗な、あるいは良い設計を定義できますか？
「私が上手に読めないのでこれは汚いです」「複雑な構造になっているので悪いです」
こんな風に考えている人はいませんか。
良い設計とは「プロダクトの本質的な複雑さが正しく反映されている」ことだと私は考えています。"正しく"、は必要なぶんだけ、と言い換えてもいいかもしれません。
さて、ではそのプロダクトの本質とやらはどうやって見出せばよいのでしょうか？ドメインマスター呼ぶ？屏風から出す？ 貴方が作ろうとしているプロダクトは世界に前例がない、あるのは脳内のボンヤリした勝ち筋だけ。正解をどう定義する？グズグズしてたらライバルがイケてるやつ出しちゃうかも、もしかしたらGoogleが無料で似たようなものを出して焼畑しかけてくるかも、MicrosoftがカタログスペックだけのモックをリリースしてOfficeにバントルしてくるかも！！！
せや、さっさとベータ版をリリースしてユーザーの反応みればいいじゃん！
つまり
正しいかどうかもわからないものを
とにかく最小手でリリースして素早く失敗して
というのがスタートアップの定番パターンです（もちろん例外も沢山ありますが）。
超天才なら最初から正解がわかるから未来の最適解アーキテクチャでしっかり作り込めるぜ……そう考えていた時期がオレにもありました。
もうね、↑の3ステップでこの記事で言いたいことおわっちゃった。
アーキテクチャを考えるのが得意なプログラマーを雇用できれば失敗の数を減らしたり、より多くの改善に耐えうる冗長性をもった設計を初手で行えるとはおもいますが、やはり無限の改善サイクルに耐えうる設計を人類が行うのは不可能で半年も経つころには技術的負債が山積みになります。 技術的負債が蓄積……？負債が蓄積するとはどういうことでしょうか？
ある程度軌道にのったプロダクトをスケールさせたい！！！
破産すれば負債は爆発四散します。
無になっていないということは、貴方のプロダクトはユーザーを無事に獲得して成長中です。
開発のフェーズも変わってきます。
最初期はとにかくリリースと仮説検証が重視されていましたが、サーバーの安定性、負荷対策、スケーラビリティ……UIもオシャレに使いやすく、離脱やCSコストを減らしたい……
えっ、無限の改修作業でぐっちゃぐちゃになったアーキテクチャのままマイクロサービス化！？
だいたいこの辺で会社が拡大して新規メンバーを雇用します。クソ設計（に見えるけど初期は最善手だったもの）を現代的にしようと苦心する新規メンバーとか、スケーリングフェーズの技術セットに微妙に疎い戦闘民族系古参メンバーとの軋轢、文化的断絶、その辺が理由で組織が崩壊しはじめるのがこの辺です。
当たり前ですが「さっさとリリースして失敗して失敗だったら簡単に捨てられる設計」は大抵の場合において「安定性が高くてスケールする設計」と大いにコンフリクトします。
「誰もが140字制限で書き込める、ゆる〜く繋がるSNS！」の初期設計に「極東の変な国が毎年年末になるたび全員一斉に滅びの呪文を唱える」耐障害性を加えようと画策する天才がいたらそいつはクビにしないといけません。
初期は簡単だとおもって軽視していた部分が、あとから実はとっっっっても重要で複雑なドメインであったことが発覚するのはまれによくあることです。
つまり、
「正しく開発したスタートアッププロダクトの初期設計は、正しく成長した未来からは壊れた設計にみえてしまう」
ということです。
誇っていい成果ってこと。