コレクションとDataGridViewの間に双方向のデータバインディングを提供するには、UIにBindingListが必要です。ただし、ビジネスレイヤー（またはドメインレイヤー、サービスレイヤー、データレイヤーなど）からBindingListを返すのは正しくないようです。つまり、UI要件のためにBindingListのみを使用していましたが、このUIの必要性はドメインレイヤーと結合されます。
これを行うための「適切な」分離された方法は何ですか？IListを返し、プレゼンテーションのためにBindingListにコピーする必要がありますか？現実の世界の観点から、このオーバーヘッドは何か価値がありますか？
IListのコピーはありません（少なくとも、コピー/クローンを作成したくないと思います）。通常行うのは、同じIListオブジェクトに別の参照を作成することだけです。したがって、IListオブジェクトを返すことは悪いことではありません。
たとえば、Listオブジェクトを返し、バインディングリスト（UIにあります）から参照することができます。
私の意見では、BindingListよりもIList（List、HashTable aso）オブジェクトを返す方が良いと思います。これは、前者をさまざまなUI（Console、Web、Win、Service）で使用できるためです。たとえば、bindingListを使用しても、Webアプリケーションでは何の利点もありません。
「適切な」方法が何であるかはわかりませんが、過去にCSLAのようなフレームワークを使用したことがあり、ビジネスリストにBindingListとObservableCollectionを使用したことを知っています。これにより、アイテムがリストに追加またはリストから削除されたときにUIが更新されるため、UIでビジネスオブジェクトを使用することが非常に簡単になりました。IListを返し、それをBindingListにコピーする場合は、IListへの変更を手動で監視および処理し、それらをBindingListに変換する必要があります。私の個人的な好みは、可能であれば、BindingListまたはObservableCollectionを使用してビジネスレイヤーをUIに表示する機能豊富なビジネスレイヤーを用意することです。
ドメイン層はより一般的な型を返すと思います。通知するかどうか（ObservableCollection<>）かどうか（IEnumerable<>またはIList<>）は要件に応じて異なります。
UIレイヤーは、その機能が必要な場合に、必要に応じて（または不要に）IBindingListに変換することを処理できます。
BindableLinqを使用して、UIレイヤーで（場合によってはフィルターを使用して）バインディングリストに通知/同期するという目標を達成するために大成功を収めました。
独自のイベントハンドラーを実装せずにUI要素でビジネスモデルを編集する場合は、ビジネスモデルにBindingListが必要です。
new BindingList<MyWidget>( list )ルートリストからバインディングを切り離しているようなことをするときはいつでも。アイテムを編集すると、すべて正常に機能しますが、追加と削除は元のリストに反映されません。
最近、BindingListListChangedイベントを利用して、このような実装を試みました。これにより、BindingListの変更を反映するようにモデルが更新されましたが、コントローラーによってモデルが変更された場合、UIのBindingListは更新されませんでした。
リストにアイテムを追加またはリストから削除するたびにイベントを発生させる特別なアクセサーをリストに作成することもできますが、これは、より多くのオーバーヘッドを伴うBindingListホイールを再発明するだけです。