jdutheil / booking-ddd

5 stars 1 forks source link

Mixing of concerns #5

Closed tclasen closed 8 months ago

tclasen commented 8 months ago

https://github.com/jddw-dev/booking-ddd/blob/f2d6694ee69d5fec343ca45c98130f9fcd8af40c/src/modules/booker/commands/create-booker/create-booker.http.controller.ts#L18

API controllers are a part of the application details and not part of the bounded context. This only works because your project is simple enough to be better off as a CRUD application. By decoupling your domain from the API you can allow yourself to have a single API route that touches multiple domains at the same time, or no domain at all. It also allows you to reuse your domain code for other non-HTTP entrypoints such as a CLI or just a task worker.

Moving the handler out of the bounded context will also cause you another problem that is good to consider anyway. You can now only utilize the public interface of your bounded context / aggregate from the API handler, no more can you reach inside the domain and manually do actions. This means your API will be using the exact same interface you are using in your unit tests, which is a REALLY good thing to do.

jdutheil commented 8 months ago

This one also makes my life much more easier ; I've moved RestApi to its own module under a top level infrastructure folder, and from there I will describe my API. Then it also answer all my questions related to authentication ; my RestApi module can simply use some kind of authentication (in here, Jwt) like I would do in any NestJs lambda project. When the "requests" get to my domain, everything is already authenticated and my domain doesn't have to care about that.