Hacker News Reader

Comment by ChicagoDave | Hacker News Reader

This is nothing new and generally how SOA began in the 2000’s.

One of the critical improvements to SOA is DDD (domain-Driven Design) where context matters and boundaries should include the service and its data.

Data oriented architecture a bad idea. Period.

View on HN

While it's true that SOA generally began by breaking up services into separate binaries while usually keeping one centralized database, a lot of the specific principles of DOA are a _response_ to the distribution/fragmentation of state seen in SOA and micrservices in the mid 2000s.

DOA is often implemented taking advantage of event-driven programming, pubsub, and message passing, which as generalized practices were not as prominent when SOA began, imo.

I thought it was what started the ECS architectures which are all the rage in game engines nowadays, and start bleeding in GUI and other fields too. Doesn't seem such a bad idea to me.

Nah, ECS probably got backported. On top of that, ECS as a term suffers from multiple personality disorder - there are different architectures with differing goals all bundled under the same name "ECS".

See: https://news.ycombinator.com/item?id=21897824.

The DOA in this article is not the same data orientation the game industry talks about. This article has nothing to do with storing your data in arrays for tight looping.

I am skeptical of blanket statements like that. I’ve yet to meet a (real) language or tool or architecture that doesn’t have merit.

Even "Big Ball of Mud"-design has some benefits: http://www.laputan.org/mud/

If you have a simple system, fine. If you have a complex system, any hint at a monolithic future has the makings of bad architecture.

Data storage should reflect a bound context and its domains. It could be relational, graph, document, or key/value.

Putting all data in one place just because it’s convenient is ignoring your business capabilities.

DDD proves that aligning your technology to our business, reducing complexity, having real boundaries, is the way forward.

functional architecture is the future: https://increment.com/software-architecture/primer-on-functi...

Any good sources on DDD?

“Domain-Driven Design: Tackling Complexity in the Heart of Software“ by Eric Evans seems to be the preeminent book on the subject.

It's valuable, but very hard to read. I would recommend implementing DDD by Vaughn Vernon first. Also understanding event storming helps a lot.

I thought this book was solid

https://www.amazon.com/Data-oriented-design-engineering-reso...

Google videos of Eric Evans and others talking about DDD, Event Storming, and CQRS.

Domain Driven Design Distilled is the best place to start. It compresses the topic down into only 200 odd pages rather than the other giant books on the subject. I'm reading it at the moment and it's starting to click far more than it ever has.

Also, don't just try to watch conference talks and read blog posts to understand it. It leaves too many gaps and a fuzzy understanding.

Reply on news.ycombinator.com