Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Analysis of Software Architectures

firatatagun.com

Post reply on HN
Print view View original

21–30 of 41 posts

Re: Analysis of Software Architectures

#21

Post by kisstheblade »

perlgeek wrote: post #19
kisstheblade wrote: post #10

Regarding microservices. They sound nice in theory, and certainly work for some cases. But what is the common pattern to handle a situation like this (in a performant and "scalable" way). Say you have two (completely separate micro-) services: - Order service - Customer service Now when a customer buys something, it is stored in the order service. But how is the customer information referenced in the order service? D…

Denormalization is often a practical answer; the order service keeps an (immutable) copy of the customer's name and delivery address. If the customer changes the address, it will only matter for new orders. One can argue that this is actually a sensible behavior, because there's a point after which you can't change the delivery address anyway (once it has been handed over to the delivery service, for example), and th…

Good point. In this case at least it is actually preferable to copy the customer data over to the order.

Re: Analysis of Software Architectures

#22

Post by hyperpallium »

alexandercrohde wrote: post #4

This analysis brings to the front a personal frustration, and I imagine it's not unique to me. This article discusses some architecture techniques, but moreover, it buys into a Culture of Architecture that we don't have a word for yet. This CoA is predominant among Java engineers who worked at large, slowly-dying companies (e.g. IBM). The issue with the CoA is that it cares more about buzzwords than quantifiable clai…

"Architecture astronauts"

Re: Analysis of Software Architectures

#23

Post by jimbokun »

amelius wrote: post #7
perlgeek wrote: post #6

This articles makes the assumption that features are easier to develop if subsystems are broken up into separate components, with separate data sources and deployments. But experience shows that this is only sometimes the case. Monolithic applications with a big SQL engine as the backend have the advantage that you can do joins very easily. If the data is split into three microservices, you spend much more time think…

I guess that not just the joins become more difficult in a partitioned system, but especially transactions. Maintaining transactional consistency across multiple services seems to me like a nightmare. Even writing tests that address consistency could be very difficult.

And it's not a coincidence NoSQL systems often punt on joins and transactions in order to scale. Both are really hard to make both correct and efficient in a distributed environment.

Re: Analysis of Software Architectures

#24

Post by alexandercrohde »

cbd1984 wrote: post #15
alexandercrohde wrote: post #4

This analysis brings to the front a personal frustration, and I imagine it's not unique to me. This article discusses some architecture techniques, but moreover, it buys into a Culture of Architecture that we don't have a word for yet. This CoA is predominant among Java engineers who worked at large, slowly-dying companies (e.g. IBM). The issue with the CoA is that it cares more about buzzwords than quantifiable clai…

OK, help me understand: Is there any difference between CoA and design patterns? Sure, "Broker topology" is probably trivial, but so's Chain Of Responsibility and Decorators and everything else the Gang of Four touches on. So, are you just as opposed to design patterns as CoA?

I want to be clear on this, I am not at all opposed to design patterns. I am not opposed to architecture. The part of CoA that bothers me is the C (culture).

That is to say: There are many great problems to solve and some reusable strategies that can be employed to solve them. However, in my experience (such as this article), many people who talk most loudly/frequently about architecture are parroting this complex and unquestioned set of assumptions and behaviors (read: culture) in a counterproductive way. Again, those behaviors include: reinventing a complicated words for simple ideas (and using them in front of audiences without defining them), creating UML diagrams even for audiences they don't expect to know UML, focusing on adding a lot of new named "patterns" to their mental book of patterns.

For example, since somebody brought it up, take CQRS. Firstly, the way Fowler and Wikipedia explain this are vastly different, if not contradictory (indicating an issue). Secondly, it can be explained (the wikipedia version) as [to quote wikipedia] "methods should return a value only if they are referentially transparent and hence possess no side effects." This has so many exceptions I wonder why it justifies its own acronym.

And the perhaps worst of all part of this culture is that members of the culture then find a need to explicitly use all of these patterns in the most verbose ways. The more obscure the pattern and the more complex, the better they feel, like a 15-year-old who just discovered a thesaurus. Pretty soon they have 3 classes named things like MessagingLoopInterpreterInterface to achieve very basic things.

Re: Analysis of Software Architectures

#25

Post by TeeWEE »

I think the article is not bad. It just mentions some patterns and compares them. of course they can be composed.

While I agree an "architectural astronaut" approach to software engineering is wrong, we still have to understand the main underpinnings of software engineering. data, separation of concerns, composability, state vs non stateless.

recognizing patterns in granular code as well as in system composition is important. And naming them makes communication easy. PubSub, Visitor, Mvc, etc are still useful names.

What I think is funny is that the java implementations are often big compared to the same solution in functional languages.

Static OO languages often need "software patterns" such as wrapper objects, where they are nonexistent in functional languages. imho

Re: Analysis of Software Architectures

#26

Post by jjoonathan »

extrapickles wrote: post #14
alexandercrohde wrote: post #4

This analysis brings to the front a personal frustration, and I imagine it's not unique to me. This article discusses some architecture techniques, but moreover, it buys into a Culture of Architecture that we don't have a word for yet. This CoA is predominant among Java engineers who worked at large, slowly-dying companies (e.g. IBM). The issue with the CoA is that it cares more about buzzwords than quantifiable clai…

This frustrates me as well. It's not just limited to the Culture of Architecture, a bunch of concepts in software seem to have similar issues (MVC vs MVVC, REST, etc). Unlike a bunch of other disciplines, there is a distinct lack of thought into what should be applied for each application problem. Electronics textbooks generally mention that a circuit is best for a specific set of applications, and talk about some of…

Huh, I didn't think about it until now but I'll anecdotally confirm your EE vs SWE observation. Then again, maybe I'm just far enough from the center of the EE scene that I don't get hit by as much dogma. Hard to tell.

Re: Analysis of Software Architectures

#27

Post by locafoca »

alexandercrohde wrote: post #24
cbd1984 wrote: post #15

Earlier quoted context omitted.

OK, help me understand: Is there any difference between CoA and design patterns? Sure, "Broker topology" is probably trivial, but so's Chain Of Responsibility and Decorators and everything else the Gang of Four touches on. So, are you just as opposed to design patterns as CoA?

I want to be clear on this, I am not at all opposed to design patterns. I am not opposed to architecture. The part of CoA that bothers me is the C (culture). That is to say: There are many great problems to solve and some reusable strategies that can be employed to solve them. However, in my experience (such as this article), many people who talk most loudly/frequently about architecture are parroting this complex an…

I feel the same way much of the time.

However, I think much of the value of having design patterns and fancy vocabulary for architecture boils down to having simple, short names for complicated, yet common, patterns and principles.

For example, if you're being onboarded into a team of twelve to develop an already somewhat large product, the phrase "it's an n-tier application, with many of our older models' data access layers using some kind of CQRS" is immediately meaningful and useful to you, in the same way referring to 1000+ line objects as "adapters" or "aggregates" is meaningful and useful to you.

Having this vocabularly enables communication of an intended purpose and responsibility for arbitrarily large swaths of code in a way that boilerplate documentation and tests can't.

(Naturally, if you're writing something from the ground-up, or you're one of a small handful of developers on the project, the value of this is somewhere between negative and negligible, which might explain the polarization of opinion on this topic...)

Re: Analysis of Software Architectures

#28

Post by hnruss »

The chart at the bottom of the article is incorrect in at least a few spots:

- The article does not identify difficulties with testability or development of the MicroService architecture.

- The face shown for Layered architecture's "Development" is colored incorrectly (since it is a smiley-face and the article text supports that).

Re: Analysis of Software Architectures

#29

Post by Terr_ »

skrebbel wrote: post #13
alexandercrohde wrote: post #4

This analysis brings to the front a personal frustration, and I imagine it's not unique to me. This article discusses some architecture techniques, but moreover, it buys into a Culture of Architecture that we don't have a word for yet. This CoA is predominant among Java engineers who worked at large, slowly-dying companies (e.g. IBM). The issue with the CoA is that it cares more about buzzwords than quantifiable clai…

I violently agree, and I suspect most of HN does. There's an associated danger though: I find that many startup hackers actively dismiss good ideas (and even entire programming languages) simply because they smell a bit of CoA. Even the CoA crowd occasionally comes up with truly good ideas that have way more substance to them than the meaningless patterns mentioned in this article. As an example: My personal pet peev…

At work I've been implementing some rough CQRS/DDD stuff for "the 2.0 system", and I'd summarize them as:

CQRS: Writes/commands and Reads/queries are fundamentally asymmetrical. Accept it and take advantage of it by having separate pipelines with different features.

DDD: Collaborate with the business-folk to discover their mental-model, and treat it and the code-model as similar co-evolving pieces. Focus on behavior and rules more than pigeonholes for data. Use Repositories to handle how RAM is not infinite, and Services for stuff you truly can't fit into meaningful objects.

Re: Analysis of Software Architectures

#30

Post by Terr_ »

perlgeek wrote: post #20
skrebbel wrote: post #13

Earlier quoted context omitted.

I violently agree, and I suspect most of HN does. There's an associated danger though: I find that many startup hackers actively dismiss good ideas (and even entire programming languages) simply because they smell a bit of CoA. Even the CoA crowd occasionally comes up with truly good ideas that have way more substance to them than the meaningless patterns mentioned in this article. As an example: My personal pet peev…

> As an example: My personal pet peeve is the startup world's ignorance of Domain-Driven Design and CQRS (Command-Query Responsibility Segregation). If you want to make scalable backends, I really recommend you read up on CQRS, it's practical and it fits modern ideas. Most examples are in C#, but you'll survive. Most starts never become successful enough to have to worry about scalability; in fact, if they do, it's a…

It's very easy to do CQRS without Event-Sourcing. ES is really a separate kind of architecture-piece that's concerned with how you mutate your persisted data.

For example, at work I've got a CQRS system where the MySQL database looks pretty much like you'd expect from any other system. (Customers table, one row per customer, etc.) It's still CQRS because writes and reads occur through different paths, and writes can have side-effects to proactively-build readable data. For example, "Top 100 Happiest Customers" might be its own table--managed by application code--rather than view or query.

Post reply on HN