[globular-toast]

Keep things as simple as possible, but no simpler. The point of this isn't to introduce complexity for no reason, it's to free up the domain model of an application from low level details like persistence, i/o, network protocols etc. What's the Rust way to do that?

[Avi-D-coder]

What the author calls bad code is one way of writing idiomatic Rust. There are more complex techniques.

It's recommended to not split the low level details from. your business logic, in fact it's not just recommended the compiler slowly forces your hand.

If you write overly abstract code like the author recommends you will leave a large amount of performance on the table. Code like that doesn't play nicely with lifetimes, by trying to separate memory management from business logic you're left with only the least restrictive scheme owned heap allocated data.

The Rust type system teaches you not separate concerns, without giving up the ability to reason about your code.

[vilunov]

I'm sorry, but depending on abstract classes does not "free the domain model of an application of low level details". The details are always there, but they could be tucked away inside other classes (structs/types) that higher ones depend on. These low level classes need not to be abstract, it will just make discovering code harder and provides nothing to improve separation of concerns.

[globular-toast]

I didn't say it did. Using abstract classes is not the goal. The goal is to free the domain model from the low level details. This can be done and these architecture patterns are supposed to achieve that. In other languages you use a lot of abstraction to achieve this. If this isn't how it's done in Rust then it would be good to know how it is done. I want the low level details to depend on the business logic, that's all. That means the business logic is clear and testable independent of any low level details.