Live data from Hacker News

A Theory of Software Architecture

danuker.go.ro

61–70 of 246 posts

Re: A Theory of Software Architecture

#61
The fundamental problem of writing about architecture: The concerns about decoupling and layering is only relevant in complex software. But an article need to present simple examples to be readable.

In this case, the first listing is simple and easily readable.

Re: A Theory of Software Architecture

#62

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…

If so, then please add 2 comment lines above each "chunk", for faster human reading, and everyone will be happy:

// build URL

// find "definition"

Re: A Theory of Software Architecture

#63

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!

This is the feeling I get most of the time in these 'let me explain software architecture in 1 post' articles. You see, I agree with pretty much everything in the article and write code like that all the time. Because yes, it does work. But you learn stuff like that automatically after a couple of years. Still, this is just one simple function; the actual hard part is scaling that to 1k+ functions while still maintaining something clean and understandable. Sure you can draw this in an onion diagram, but actually executing that in real life is something else, and I almost never see practical examples of that in online articles simply because that is not possible I guess, only in actual code or in more alaborate books.

Re: A Theory of Software Architecture

#64
Nice and all, but It feels quite pompous to tout this as a grand unified theory of anything. This is a highly specific little corner of software architecture, and is neither grand, unified or even a theory.

Re: A Theory of Software Architecture

#65

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 don't think this is a very good example of clean architecture; this is just a refactoring that extracts three methods. There's no dependency inversion used here, which is one of the key tools you would use to create a clean architecture. The use case itself depends directly on the functionality in requests, which means the business logic is coupled to the concrete details of the requests API.

Clean architecture also differs from n-tier in that–although there are layers, they don't have to be physically distinct and the APIs between them are not typically heavyweight gateways designed to work across network boundaries etc. The key design activity in CA is reducing the coupling between abstract business logic and the concrete code that executes it. It's actually quite a simple approach to describe, but more difficult in practice.

There's nothing particularly wrong with the first function; functions certainly don't only have to "do one thing" in clean architecture.

Re: A Theory of Software Architecture

#66
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.

If the people asking you to solve a problem don't know what problem they want solved then there isn't much you can do except try to solve something and see if they complain.

You could argue that you should talk more with the stakeholders, but most of them don't have the skills required to accurately identify their own problems. Instead they need to see something running and then notice when things are missing, which is why we start building stuff without knowing what problem we ultimately are supposed to solve.

Re: A Theory of Software Architecture

#67

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…

This reminds me of Brian Will's "Object-orientation is Bad" where he makes the case that most decoupling tends to be more confusing than long-form code that's got sufficient comments.

https://youtu.be/QM1iUe6IofM?t=2235

Re: A Theory of Software Architecture

#68

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…

If that is a simple 10 line script, I agree. But if that is part of an application, you will not be able to properly test it - so you either have to do time consuming manual tests or time consuming integration tests. Splitting it into different parts allows to write unit tests and smaller integration tests. Then, when you only change the "pure" parts, you only have to verify the unit tests. That gives a HUGE productivity boost in bigger applications.

Re: A Theory of Software Architecture

#69

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…

This reminds me of Brian Will's "Object-orientation is Bad" where he makes the case that most decoupling tends to be more confusing than long-form code that's got sufficient comments. https://youtu.be/QM1iUe6IofM?t=2235

I love his series. Eye opener for beginner coders.

Re: A Theory of Software Architecture

#70
post #40

Earlier quoted context omitted.

Software architecture involves HR? You can just change around definitions all you want, but don't expect the rest of the world to agree.

There is no consensus about the definition of software architecture. http://beza1e1.tuxen.de/definitions_software_architecture.ht...

None of those includes human resources like programmers as a part of software architecture.
Post reply on HN