Software Architecture Guide • Hacker News Board

Re: Software Architecture Guide

#301

Post by hyperpallium » Tue, Aug 27, 2019, 1:05 PM UTC

eitland wrote: post #298

hyperpallium wrote: post #291

Earlier quoted context omitted.

Let's be clear: I think (i) the book is great and (ii) your rude and inaccurate comment was not. (i) I said: > It's still great though (ii) I said: > lacks data You replied: > It is the computer book with most tables pr page of any I have seen. > How you come to this conclusion is beyond me. In case you were wondering, this is the part where you apologize handsomely.

Can you explain what is rude? I am not a native speaker so I just looked up the phrase you seem to point to and the two first definitions says it means: - Very difficult for one to comprehend or do. - not something that I can understand Am I missing something here? Besides, I feel you moved the goal posts early on. I replied to you talking about the whole book, you replied with a single example. Please let me know if…

Can you cite one table of data from the book?

It's the implication my conclusion was foolish; but if you intended no insult, that's good enough for me.

Re: Software Architecture Guide

#302

Post by Spearchucker » Tue, Aug 27, 2019, 7:03 PM UTC

extra_rice wrote: post #296

Spearchucker wrote: post #256

Earlier quoted context omitted.

That's the point. And yet Fowler objects because it violates encapsulation and information hiding, because it requires a service layer and makes a model less expressive.

You can easily serialise a well fleshed out (i.e. non-anemic) object. Does the view layer in this particular example need to know the encapsulated business rule? In my experience, not usually. Otherwise, there's most likely a problem with responsibilities. And when that data comes back from the UI, it's also relatively easy to reconstitute it back to well fleshed out objects.

This I know. The point isn't how one might do it, or whether it can be done¹. The point is that Fowler has issues with anemic objects, even though there are patterns in distrubuted computing best solved by anemic objects.

¹ Note that reconstitution does not do away with anemic objects - reconstitution does not implement logic in a purely object-oriented way, i.e. the logic does not travel, but the data does.

Re: Software Architecture Guide

#303

Post by tsarquitech » Thu, Aug 29, 2019, 2:09 AM UTC

We see that Martin Fowler is influenced by Ralph Johnson in deriving for himself a definition of architecture. In particular,

there was no objective way to define what was fundamental, or high level

And goes on to lean heavily on the idea that ‘application architecture' is a social construct. But I am then left with a thought that if application architecture is a social construct, that means there should be identifiable social characteristics that make-up the application architecture, characteristics that can be further quantified to an acceptable degree, such that they can be defined as fundamental.

Taking a step back from Martin’s influence & conclusion, and ask ourselves, “couldn’t software architecture, or architecture in general, be defined by a set of heuristics that lead to objectively defining what is fundamental to a particular context?“

Suppose we create three rules that need to be defined before reaching our conclusion:

- context: what scale does the architecture in question reference?

- collection of computing elements: what are the computing elements (this can range from machines to software)

- connectedness: how are the computing elements connected?

For example, in order to determine the architecture of my web scraping local machine setup I would go through the rules:

- context: a single script file with code written to accomplish the task

- collection: functions that are used to perform the task of scraping the webpage

- connectedness: functions pass data to other functions to perform specific tasks of scraping

In this example we have a guide to achieve objectively what is fundamental to our architecture.