18 comments

[ 5.1 ms ] story [ 41.7 ms ] thread
Both the book, the blog post, and this HN submission are deeply wrong on one thing: it should be called "software architecture", instead of simply "architecture".

You might say: the audience would think of software, it's unnecessary to specify... Perhaps you're right. I still think that a distinction would serve us well.

I personally disagree. The title is succinct and well understood by people in this domain.
I’m a software engineer with 10+ years of working experience. Currently working at FANG.

When I see the word architect I think about architecture. Not software architecture.

Immutable is another common software domain word. An article posted to yCombinator's "Hacker News" titled "Immutable Architecture" could refer to edifaces that don't change (?) but I was not surprised to discover that it refers to software architecture.
I think you are right.
It'd be fine if 'immutable' wasn't also very commonly used in the directly adjacent domains of systems and security architecture.
I see roles like Evangelist and Tech Evangelists. Even Tech is not about Software (one of the coolest techs people talked about in 2020 is mRNA) Hope those get explicitly named as well.
implicit val industry: IndustryType = IndustryType.Software
I also thought it meant other architecture.
Sorry, I just copied the title of the website. I'm not sure how to update this post.
I'd listened to the podcast about it on software engineering radio and thought it has some interesting concepts.
I see no content except a book blurb. Is this more than advertisement/spam?
It would be better to show the table of contents.
https://www.apress.com/us/book/9781484259542#

There's the Apress page with ToC for you.

What is the point in selling the 12 chapters individually? Plus the book at $40 or $50 makes one chapter for $30 feel silly at best.
I found that, too, but only the chapter titles don't tell you much, do they? What do you make of "State Transitions" or even "Patterns"?

For instance this is Chapter 2 "Forms of Immutable Architecture":

Deriving State from History 29 Historical Records 30 Mutable Objects 31 Projections 33 Event Sourcing 35 Generating Events 35 CQRS 36 DDD 37 Taking a Functional View 39 Commutative and Idempotent Events 40 Asynchronous Model View Update 40 The Update Loop 41 Unidirectional Data Flow 43 Immutable App Architecture 44 Historical Modeling 45 Partial Order 46 Predecessors 47 Successors 48 Immutable Graphs 50 Collaboration 51 Acyclic Graphs 52 Timeliness 53 Limitations of Historical Modeling 54 No Central Authority 54 No Real-Time Clock 55 No Uniqueness Constraints 56 No Aggregation 57

That sounds quite interesting, however with about one page spent on each topic won't go very deep.

Somewhat off topic - what do people think of Apress as a publisher?