-3

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:

  1. 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.

  2. 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 .

2
  • "developer with complete domain knowledge"- That's the problem right there. You, the dev, are an outsider to the business, and you're trying to build a tool for something that is, ultimately, not your expertise. You're going to get your requirements, and you're not going to question them. You're going to understand them in a certain way, and you're going to make certain assumptions, and they are going to be wrong, and you won't know it. You are going to make people do things they don't care about because you decided that a data structure absolutely must stay consistent at all times. 1/2 Aug 7 at 21:38
  • 1
    So, for example, you analyzed the requirements (that, perhaps, you didn't gather yourself), and you inferred a shop cannot sell an item they don't have in stock. That made sense to you. But this shop doesn't operate that way, because 99% of the time they can just order the diff, and they don't mind issuing a refund and an apology the other 1% of the time. But nobody notices this until after after you deploy. And now, for a while at least, the workers are stuck with this software imposed on them that doesn't do what they need, and they hate it, and have to come up with workarounds. 2/2 Aug 7 at 21:38

1 Answer 1

3

You're not required to use DDD, at all. But it can be a useful tool.

You say:

Initiates creative collaboration between technical and domain experts
Is this not handled by the front-end?

DDD is not about how users interact with your system. Part of DDD is how developers interact with domain experts – how things work on a people level. For example, DDD recommends that you create Bounded Contexts in which terms have meanings that are understood by both the subject matter experts and developers. The code should then also use these terms to avoid confusion. E.g. it would be a problem if your backend talks about “users” and the SMEs talk about “leads”.

You're correct that the frontend could translate between developer-speak and user-speak/SME-speak, but that misses the point: that in order to enable communication during the development process, people should be able to talk to each other using the same terms.

10
  • But if you are developing both the front-end and the back-end of the app, former should be in your head when working on latter, so why is back-end so special, specifically the business layer, that it must explain the entire application logic. Things happening on the front-end are also useful for the explanation / communication of business logic.
    – Desperado
    Aug 7 at 17:37
  • @Desperado It is not special. Both front-end and back-end are part of the same system. It is not unusual to have a front-end so complex that it also contains domain-layer aspects. But in a web context, the frontend is not trustworthy so that all relevant domain operations will be performed in the backend, with the frontend only serving as a thin presentation layer, possibly with some responsibilities of the application layer.
    – amon
    Aug 7 at 18:01
  • 2
    @Desperado The point is not the backend vs the frontend, the point is that you will get the business logic wrong. You say, in your question, "Entire domain might not visible to all the users". No, the domain is very much visible to the users, because the domain is not your application, the domain is what they do every day. It's the work they do, the procedures they follow. They live the domain, and your application is just a representation (a model) of the domain based on your necessarily limited understanding of it (since you are an outsider). Aug 7 at 21:48
  • 1
    @Desperado "why bother creating another layer of abstraction in the back-end which job is to help you understand the domain" - where did you get this idea? Aug 8 at 0:25
  • 2
    I don't see anybody saying that anywhere; indeed DDD really has nothing at all to do with the implementation or solution design, it's about requirements analysis and how to build a conceptual model. Developers may choose whatever solutions they see fit, but it's important to be consistent with the domain model to prevent disconnect between developers and non-technical people. For example, if a domain has a "shopping basket" but that name is absent from the implementation and developers instead use something else like CustomerItemList then that's likely to harm communication. Aug 8 at 16:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.