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

31–40 of 41 posts

Re: Analysis of Software Architectures

#31

Post by platz »

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…

> 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 simply isn't even accurate at all; that "it can be explained" as such is just plain false.

Re: Analysis of Software Architectures

#32

Post by paulddraper »

virmundi wrote: post #11
amelius wrote: post #7

Earlier quoted context omitted.

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.

Often you don't worry about transactions across services. I know that someone will say we have to have them. In such cases, fine worry about them. In everything else, either isolate the write side of a transaction in one service or don't require them.

"don't require them".... Transactionlity is principally dicated by the requirements to the architecture design, not the other way around.

" isolate to one service " Yep, a single service with a single database, as mentioned.

My point here, like the earlier one, is that there are a lot of situations where multiple services don't fit the domain. In fact, very many, given the extreme complexity around transactions.

Re: Analysis of Software Architectures

#33

Post by Terr_ »

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…

Right, I think this is an example of the importance of good requirements and scenarios before coding.

While programmers may prefer to create denormalized "model of everything at once", some business processes require copies and snapshots. Not as implementation details, but directly.

Re: Analysis of Software Architectures

#34

Post by [deleted] »

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…

[deleted]

Re: Analysis of Software Architectures

#35

Post by [deleted] »

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…

[deleted]

Re: Analysis of Software Architectures

#37

Post by perlgeek »

Terr_ wrote: post #30
perlgeek wrote: post #20

Earlier quoted context omitted.

> 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…

If you do it that way, you don't get the famed scalability; it's still limited by the scalability of the mysql backend.

Re: Analysis of Software Architectures

#38

Post by sampsonetics »

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…

Unfortunately, the Wikipedia article [1] doesn't distinguish between CQRS (command-query responsibility segregation) and CQS (command-query separation). They are entirely different concepts. Compare Fowler's CQRS article [2] to his CQS article [3].

CQS is an old OO design principle suggesting that an object's behavior is easier to reason about if every method either changes the state of the object or interrogates its current state. That's not always possible, but it's a helpful habit.

CQRS is the idea that use cases involving searching and reporting across many entities are fundamentally different from use cases involving interactions with particular entities. It is therefore sometimes worthwhile to develop separate data models for searching and reporting that are updated asynchronously.

[1] https://en.wikipedia.org/wiki/Command–query_separation

[2] http://martinfowler.com/bliki/CQRS.html

[3] http://martinfowler.com/bliki/CommandQuerySeparation.html

Re: Analysis of Software Architectures

#39

Post by skrebbel »

perlgeek wrote: post #37
Terr_ wrote: post #30

Earlier quoted context omitted.

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…

If you do it that way, you don't get the famed scalability; it's still limited by the scalability of the mysql backend.

The codebase is, however, very well structured to make that change later on.

You don't need to do a lot of CQRS to make future scalability a relatively simple redesign.

Re: Analysis of Software Architectures

#40

Post by jtmarmon »

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…

You can do a cross service join in a single request. Combine that with good caching and a normalized architecture is (almost) as performant as a demoralized one.

Check out https://github.com/facebook/dataloader

We use it to do cross service joins in the form of bulk requests in a very transparent way.

Post reply on HN