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

A Theory of Software Architecture

danuker.go.ro

Post reply on HN
Print view View original

51–60 of 246 posts

Re: A Theory of Software Architecture

#51

Post by cies »

speedgoose wrote: post #32

I understand that the point of his example is to introduce the reader to a variant of the very classic multitier architecture with layers. https://en.wikipedia.org/wiki/Multitier_architecture But I prefer the first version of the example, because while it's named "complex code" I think it's the simplest version. I think that there is no need to decouple this simple and straightforward function in three functions that…

I find the Multitier Arch (MA) has much better names.

The arch proposed by the article has "Application Business Rules" (ABRs) and "Enterprise Business Rules" (EBRs). Now in a small start-up, what are the "enterprise rules", is "enterprise" not merely a buzzword in this context? And how ABRs and EBRs differ is not well explained.

In MA this is much clearer: the Data Access Layer (DAL) contains DAOs (the persistence side of the model in MVC), Business Layer (BL) contains the business/domain logic (the other side of the M in MVC and/or the business logic that may end up in the C of MVC; aka services in Rails), the Application Layer (AL) contains what would be typical "controller logic" (authorization/redirection/data gathering for the presentation) in MVC and the Presentation Layer (PL) contains the V from MVC.

> [...] I think it's important to not overly do it.

Yups. So maybe one can do without a BL at first, and put the business logic in the DAL at first and dont mind to have a litttttle bit of it creaping into the AL (controller).

Re: A Theory of Software Architecture

#52

Post by ghosty141 »

speedgoose wrote: post #32

I understand that the point of his example is to introduce the reader to a variant of the very classic multitier architecture with layers. https://en.wikipedia.org/wiki/Multitier_architecture But I prefer the first version of the example, because while it's named "complex code" I think it's the simplest version. I think that there is no need to decouple this simple and straightforward function in three functions that…

Lile the author wrote, the example is only an example, in the real world those functions are way bigger. Such a small function would be fine but most functions are far bigger and often call other functions that again do some IO.

Re: A Theory of Software Architecture

#53

Post by OneGuy123 »

Another "academic level" demonstration that doesn't work in practice.

It's so simple to say "look how awesome this approach is" on a 50 line program, "just use pure functions everywhere".

In real life things get very complex because there are 200 working parts interconnected. And not because "it's bad design". But because that is the requirement. Soon you get pure functions with tons of parameters or parameters that are complicated classes/structs themselves because the work that needs to be performed is very complicated.

Then you get to the issue of "this function gets the entire class as the input param but it only access a small amount of members in that class".

"Yo bro just split the class into multiple smaller ones". Sorry bro can't do, those separate classes will need to be acccessed as a whole sooner or later in another part.

People act as if there will ever be a thing such as a "perfect programming design". There won't because things will always evolve & change. Real life programs are simply too complex.

Re: A Theory of Software Architecture

#54

Post by OneGuy123 »

barumi wrote: post #49
layoutIfNeeded wrote: post #11

I find it amusing how these software architecture gurus always demonstrate their teachings with a cookie-cutter CRUD app. There are software which do things other than making REST calls... Show me how you’d implement a basic MS Paint clone and we can talk!

> Show me how you’d implement a basic MS Paint clone and we can talk! A MS Paint clone is one of those apps that fits rather nicely on a Clean Architecture. You have the domain model (raster image), you have the application layer (image processing operations over the raster image), and you have the IO/service layer (image exporters/importers, GUI, platform-specific features, etc).

Are you actually a programmer?

You sound more like an academic with no real life experience on large software.

You do realize that within those "neatly separated layers of yours" there will be an insane amount of complexity which will be impossible to separate in layers?

Re: A Theory of Software Architecture

#55

Post by berkes »

rsa25519 wrote: post #45
speedgoose wrote: post #32

I understand that the point of his example is to introduce the reader to a variant of the very classic multitier architecture with layers. https://en.wikipedia.org/wiki/Multitier_architecture But I prefer the first version of the example, because while it's named "complex code" I think it's the simplest version. I think that there is no need to decouple this simple and straightforward function in three functions that…

Agreed. Abstractions are more mentally expensive than a single concrete idea but less expensive than many concrete ideas. When something doesn't need to be abstract, especially in a language where refactoring is easy, it should not be abstract.

Or, how I would put it more pragmatic: the first example is a sure way towards seven slightly different mechanisms to call an Api. Per year. On a team with seven devs.

Re: A Theory of Software Architecture

#56

Post by brabel »

aryehof wrote: post #38

To me, a software architecture is an implementation of the decisions made (amongst competing choices) in meeting its requirements , both functional and non-functional. I simply don't find the article to provide a grand unified theory across different genres of software at all. What worries me is that newcomers to the industry will, until they move to the next discovered silver bullet unified theory.

It's a good theory for writing general code that can be easily tested and modified in the future.

This is the first thing you need if you want to meet any business requirement at all.

Re: A Theory of Software Architecture

#57

Post by antupis »

Spearchucker wrote: post #46
makach wrote: post #43

We have built software for a long time and we have learned a lot. There are many good ways (patterns) to reuse when you need to solve a particular problem. Uncle Bob speaks the truth. For me, the challenge has never been with the architecture or our combined technical knowledge. What I have observed as the main challenge is that most technologists start solving the problem before they know what the problem is.

This, so very much. It helps to spend time understanding a situation before assuming you have appropriate ideas about changing it. Management consultants (good ones may be rare, but they exist) have some pretty complex process models just to get a handle on the problem.

Personally I have found that actually understanding situation means that I write code that solves it.

Re: A Theory of Software Architecture

#58

Post by mathw »

berkes wrote: post #55
rsa25519 wrote: post #45

Earlier quoted context omitted.

Agreed. Abstractions are more mentally expensive than a single concrete idea but less expensive than many concrete ideas. When something doesn't need to be abstract, especially in a language where refactoring is easy, it should not be abstract.

Or, how I would put it more pragmatic: the first example is a sure way towards seven slightly different mechanisms to call an Api. Per year. On a team with seven devs.

Not doing the first example is a sure way towards either copying that function and changing it a bit because you need a slightly different call, or a function with a pile of branches in it because it needs to operate in several modes.

Both ways could go wrong. I don't care what your architectural choice is, you can still mess it up.

Re: A Theory of Software Architecture

#60

Post by nullsense »

jonahx wrote: post #9
kumarvvr wrote: post #2

Move most of your code to pure functions, that is the number one mantra to solve most scaling problems in software development. Even in an OOP paradigm, it makes sense to make almost all objects as purely functional, with limited use of internal state. The second mantra is to think a thousand times before you name something. I actually keep a list of names (..Manager, ..aggregator,etc.) gleaned from various sources,…

> (..Manager, ..aggregator,etc.) Names ending in Manager are usually a poor choice. See Peter Coad's "-er-er" principle: > The “-er-er” principle. Challenge any class name that ends in “-er.” If it has no parts, change the name of the class to what each object is managing. If it has parts, put as much work in the parts that the parts know enough to do themselves. See also: http://www.carlopescio.com/2011/04/your-codi…

One of my favorite classes in my code base is called something FooBarBazListenerListener
Post reply on HN