I am a full stack developer who's been learning about Domain-Driven Design in the past couple of days, so I have some question since I have trouble finding place for this pattern in my applications.
I think of front-end as this reactive programming "experience" focused on UI/UX, and of back-end as a transactional, performance oriented system. Comparing this to DDD, it sounds like a technically oriented design, more difficult to understand and talk about, and as such, more difficult to change in the future.
Now to address some supposed advantages of DDD over this design:
Initiates creative collaboration between technical and domain experts
Is this not handled by the front-end? Isn't it the way how users reason about our application by analyzing the behavior of the interface, how it processes user actions, how it reacts to changes made by those actions, how it applies business rules, etc. Entire domain might not visible to all the users, but that interface is what gives them the picture of the application.
Placing the project's primary focus on the core domain and domain logic
Doesn't my API logic and its use focus on domain logic? It defines all necessary relationships in the model, and endpoints' parameters perfectly define the units of work (alongside the code that uses the endpoint). The fact that user has clicked the increment button for a product in their cart, and provided us with
cartId, productId, quantity, seems like enough to provide context. Or the rule that says inventory must have something before incrementing its quantity, that's the same rule we enforce when we inform the user something is out of stock.
A full stack developer with complete domain knowledge will never create just an application's CRUD model, but they will create its entire behavior.
Again, just two days of experience in DDD, so I am interested in finding more about DDD and its advantages .