domain driven design - How to avoid business logic in frontend while keeping frontend interactive

Question

I am a DDD amateur, and I'm not sure I phrased the question correctly, or whether this even concerns DDD, but here is what has been bugging me about trying to implement DDD in my project.

Let's say my system is a sales order management system, where user can input sales orders with multiple lines for each order. Now the line amount can be in the base currency (of our client) or in a foreign currency, in which case it needs to be converted to the base currency by multiplying with a pre-determined exchange rate varying from month to month.

I think this amount conversion is a business rule and therefore should be in the domain layer. However I also want my user to be able to enter the amount in foreign currency and then have the amount in base currency automatically calculated and filled out in the form without the need to explicitly submit any data. This looks like it needs to be carried out on the frontend, and therefore violates the "no business rule in the frontend" rule.

How would you go about implementing this?

question from:https://stackoverflow.com/questions/65898705/how-to-avoid-business-logic-in-frontend-while-keeping-frontend-interactive

Answer 1

I think there are probably 3 main scenarios:

1. The logic already exists on the backend. In that case most obvious route when wanting to avoid duplication is to expose an API on the backend allowing the client to leverage that logic. The multi-tier interaction can usually be made almost transparent to the user assuming latency remains reasonable.

2. It's business logic, but the backend doesn't care. In your example, if the backend always work in a base currency (e.g. USD) and the exchange rate is only needed on the client then implement such logic in the client only. It becomes a client-specific concern. It's still business logic though (business logic is not limited to a specific tier), so it should be maintained as such in the client. For instance, keep that logic in client-side services rather than mixed with presentation concerns. Implement unit tests as well since it's core logic.

3. It's business logic on the backend, but there's too much latency. In that case you must duplicate as much logic as needed on the client to meet the performance goal. You could either do that manually or through code generation strategies (e.g. transpile one language to another).