DDDへの正しいアプローチ？

Question

アプリケーションで正しいアーキテクチャを使用しているかどうか疑問に思っています。

私のAPIでエンドポイントを呼び出した後、私は現在次のフローを経ています：Api.EmployeeController.Update(Api.EmployeeUpdateDto) => Services.EmployeeService.Update(Service.EmployeeUpdateDto) => Data.EmployeeRepository.Update(Entities.Employee) => Data.EfDbContext.Employees.Update(Entities.Employee)

詳細を説明するために、私のAPIエンドポイントは_Api.EmployeeUpdateDto_を取得し、コントローラー内で_Services.EmployeeUpdateDto_にマップされ、Services.EmployeeService.Update()に渡されます。 Services.EmployeeService.Update()内で、IDによって実際のdbエンティティを取得し、その値を更新します。その後、EmployeeRepository.Update()に渡され、基になるEF dbコンテキストが呼び出されます。

どういうわけか、私の腸はそれが多すぎるレイヤーで複雑であると私に言っています、私は何かが足りないのですか？

Answer 1

Api.EmployeeController.Update（Api.EmployeeUpdateDto）=> Services.EmployeeService.Update（Service.EmployeeUpdateDto）=> Data.EmployeeRepository.Update（Entities.Employee）=> Data.EfDbContext.Employees.Update（Entities.Employee

それをこのように見てみましょう。もしあなたがあなたのビジネス相手にこれを伝えたらどうなるでしょう？上記の単語ごと。

私は彼/彼女があなたが今言ったことを少しも理解していないと賭けます。

DDDの「ドメイン駆動」部分は、設計の決定がドメインによって駆動されることを意味します。その言語、その構造、その振る舞い。あなたのデザインの問題は、それが複雑であるというだけでなく、技術デザインであり、ドメインデザインではありません。