Comment by ctvo | Hacker News Reader

Comment by ctvo | Hacker News Reader

Learn both. There's nothing particularly difficult about either. They have a lot of documentation, books, open source projects to learn idioms from. Rust obviously will take longer with more language features.

I also think your alternative option is outdated. There was a fad 5-10 years ago in the .NET / C# community around DDD and to a lesser extend CQRS. You read the DDD book, took bits you could use, and attempted to build better. It wasn't a silver bullet, and took tremendous teaching / culture change to get implemented. I personally never found it worthwhile in the spaces I worked in. I feel the industry has moved on, even now, let alone the future.

My advice is to be less timid around technologies. Get better at learning. Get better at the fundamentals. An immutable ledger that separates read from write is useful in a lot of distributed systems, not only as an application design pattern. An intentional common language that all refer to is a great process / culture change to improve communication. Does it have to be mapped identically in code? It depends.

Could you expound about nowadays practices regarding best software architecture practices.

Where I live (France), using DDD is highly regarded on the job market. Employers take you more seriously when you can talk about DDD principles and practices, especially as a JavaScript developer.

Any resources ?

Is reading DDD literature like the Evans book is worth the while for a developer today?

A lot around DDD, like implementations tend to have become dated. However, the principles around a well designed domain isn't. So not sure what he refers to.

Works like from Rebbeca Wirfs-Brock, I believe it was called Object Design about roles, responsibility and interaction/collaboration is like just if not more important to me.

It boils down to, understanding the motivations behind a technology and apply when needed. Design your objects and software according to state, etc.

It is, if only to learn how some people approach modelling domains. It's rarely a bad idea to see different approaches to doing stuff. That being said Evan's book is a rather dry read.

I'd put it much lower on the list of readings.

Complex domains are still around, developers should learn them before trying to come up with solutions but they're implemented differently: As services with clear boundaries, with explicit contracts.

DDD can be applied to the boundaries of services, within API contracts so they speak a common language. The unit of encapsulation of a service makes a lot of the implementation details in the book moot.

Problems that are more relevant today are service discovery, observability, low friction of computing provisioning as organizations grow. This sounds a lot like devops concerns. It's not purely so. It's the complexity that grows when organizations expand and add functionality to their software. Its outcome, tremendous complexity, is what DDD tried to tame in 2004.

To expand on the above:

When we began switching to services as units of encapsulation, we implemented boundaries, contracts, kept business logic separate. Did we match the domain perfectly? Often not, but the API contracts between services is easier to enforce. At a high level a standard can be set on how we should speak a shared language. This is most of the benefits I took out of Evans book. It happened organically in the industry slowly.

Localized, each service is easy to reason about, test, and refactor. Great. The complexity NOW is managing and operating these services for small to medium organizations (the same ones struggled with domain modeling and design patterns to tame their monolith in a previous era).

Reply on news.ycombinator.com