4 ms·

Hasn't the use of behaviourless value objects (essentially structs) been commonplace in both the JVM and the related .NET-world for the better part of a decade

by occz 2y ago

Hasn't the use of behaviourless value objects (essentially structs) been commonplace in both the JVM and the related .NET-world for the better part of a decade now, maybe more?

neonsunset 2y ago
From my experience, "anemic DDD inspired architecture" is fairly common in enterprise .NET codebases. These do heavily use all kinds of value object, DTO and DTO-like objects with the logic that processes them being defined separately. Unfortunately, most of them still suffer from premature and very unnecessary abstraction bloat. Luckily, the trend for terseness and minimalism is gaining more and more momentum each year, with just a single 100 LOC Program.cs microservices with asp.net core's minimal API no longer raising eyebrows and causing arguments in the teams as much as it used to. Extensive support for pattern matching, records, closures (since a long time ago) and other ways to define strict and terse data structures is also helping to preserve functional nature of this approach. Note that JVM does not have structs and has a long way to go until project Valhalla becomes a reality. FWIW it has been less of an issue thanks to quite strong escape analysis as implemented by OpenJDK and GraalVM, but it does not afford the same guarantees and degree of control the structs do (not to mention lack of monomorphized struct generics as in Rust and .NET). In the "average codebase", structs in .NET have not been as popular historically, but with heavy focus on "close to the metal" features in both compiler optimizations and syntax, and increasing awareness of C# being a viable and effective systems programming language, this also is changing.
- nogridbag 2y ago
  I'm not familiar with the .NET ecosystem at all, but in general I think the problem with the "just write everything in the framework's layer" for most companies is your whole application becomes tightly coupled to that framework, and more specifically that version of the framework. That's likely a much bigger problem for monoliths which I would imagine is still the majority of apps, even in 2024. Most developers likely don't stick around long enough to see the pains of doing major upgrades on large codebases. I've been using a layered architecture with great success for a large fintech application. We've even migrated from one web framework to a completely dissimilar web framework trivially as the majority of our code in the business layer needed no changes.

by occz 2y ago

Hasn't the use of behaviourless value objects (essentially structs) been commonplace in both the JVM and the related .NET-world for the better part of a decade now, maybe more?

neonsunset 2y ago

From my experience, "anemic DDD inspired architecture" is fairly common in enterprise .NET codebases. These do heavily use all kinds of value object, DTO and DTO-like objects with the logic that processes them being defined separately. Unfortunately, most of them still suffer from premature and very unnecessary abstraction bloat. Luckily, the trend for terseness and minimalism is gaining more and more momentum each year, with just a single 100 LOC Program.cs microservices with asp.net core's minimal API no longer raising eyebrows and causing arguments in the teams as much as it used to. Extensive support for pattern matching, records, closures (since a long time ago) and other ways to define strict and terse data structures is also helping to preserve functional nature of this approach. Note that JVM does not have structs and has a long way to go until project Valhalla becomes a reality. FWIW it has been less of an issue thanks to quite strong escape analysis as implemented by OpenJDK and GraalVM, but it does not afford the same guarantees and degree of control the structs do (not to mention lack of monomorphized struct generics as in Rust and .NET). In the "average codebase", structs in .NET have not been as popular historically, but with heavy focus on "close to the metal" features in both compiler optimizations and syntax, and increasing awareness of C# being a viable and effective systems programming language, this also is changing.

nogridbag 2y ago
I'm not familiar with the .NET ecosystem at all, but in general I think the problem with the "just write everything in the framework's layer" for most companies is your whole application becomes tightly coupled to that framework, and more specifically that version of the framework. That's likely a much bigger problem for monoliths which I would imagine is still the majority of apps, even in 2024. Most developers likely don't stick around long enough to see the pains of doing major upgrades on large codebases. I've been using a layered architecture with great success for a large fintech application. We've even migrated from one web framework to a completely dissimilar web framework trivially as the majority of our code in the business layer needed no changes.