ユースケースとの契約さえ破らなければ、実際には公開インターフェースを守って雑にコードを書くだけ、という作業になります。5.では明確にフィードバックループがある訳ではないですが、ユースケースがアプリケーション統合しにくい形だったりした場合に修正することがあるかも知れません。ちなみに、実際の外部サービスやインフラとの接続のため、設定注入機構やロガーを用意するのもこの段階になります。事例PaaS等で動かすアプリケーションの場合、先にローカルマシンで動かせる形のアプリケーションを作って動くようにすると便利です。アプリケーションの実際の動作を安全に検証できるだけでなく、「インフラ構成や設定のせいかと思ったら実装コードがまずかった」という類の無駄なつまずきの予防になります。オニオンアーキテクチャでは、簡単な役割の実装やアプリケーションのエントリーポイントを差し替えるだけで、こういったものを素早く制作できるのも利点の一つのように思います。あとはユースケースを起動するだけ、という形になります。以下のような実装になりました。.get<PublishImageFileSpoilerMessage>(ROLES.PublishImageFileSpoilerMessage);usecase.serve();動作させてみましょう。一部として実装されます。