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

Software Architecture Guide

martinfowler.com

Post reply on HN
Print view View original

191–200 of 303 posts

Re: Software Architecture Guide

#191

Post by streetcat1 »

crimsonalucard wrote: post #182
streetcat1 wrote: post #99

Earlier quoted context omitted.

> The thing with Object Orientation is that it has no basis in theory or science and is almost 100% art. Absolutely incorrect. The data part of OO is based on set theory as formalised in the database design research and type systems. The dynamic part of OO is based on finite state machines. The data abstraction and information hiding part is based on the work of barbara liskov (for which she won the Turing award) - h…

>Absolutely incorrect. I said OO didn't have basis in theory or science. By basis I mean it wasn't derived from theory. Rather it was created as more of an "artistic" endeavor and later it was fit into a framework of an existing theory. You should know almost ANY system can be broken down to fit into an existing theory from a projectile object, to a flying plane, to the weather, to an object oriented programming lang…

She developed the axiomatic theory in a later book:

https://mitpress.mit.edu/books/abstraction-and-specification...

Were she propose an axiomatic theory for OO interface design.

Definitely not artistic.

The only thing artistic in OO (as someone who practice it in the last 30 years), is finding the initial set of objects. But you will have this issue with any technique.

Re: Software Architecture Guide

#192

Post by streetcat1 »

Ozzie_osman wrote: post #133
streetcat1 wrote: post #104

Earlier quoted context omitted.

Software engineering is engineering in the same sense the mechanical engineering is engineering. The only difference is that with software your materials are descriptions. I.e. you describe something, give to the computer and the computer turn itself into this something . In the end, there is a physical entity in the world (the hardware), which turned itself into a unique machine based on your description (for exampl…

I disagree. Engineering disciplines vary in how far removed they are from the underlying physics and how malleable they are. Building a bridge (or civil engineering) is very connected to the underlying physics. A set of equations give you the answers. It's also not malleable. You design it once, then build it, putting in some margins of safety to account for any variances in underlying material or potential usage, th…

There is not such thing is "partial" engineering.

Engineering is the creation and ongoing management of any real world object (building, cars, bridge, computer) which has affect on its environment. I.e. they are placed in the real world to achieve some sort of a function.

The role of the engineer is:

1) Find out what function a machine should provide

2) Create this function by building the artifact on time, and in cost effective manner.

An artist on the other hand:

1) Does not care about the function. I.e. if the thing is useful or not.

2) Does not care about the time/cost etc.

The fact that software is just a description (bunch of text files), does not mean that it does not affect the real world.

As I said, the machine in the real world is the general propose computer. The computer understand this text files, and turn itself into the machine.

Re: Software Architecture Guide

#193

Post by charlieflowers »

dvlsg wrote: post #149

His biggest contribution may be the documentation and defining the vocabulary, but when he defines a pattern with a word that has an obvious negative connotation ("anemic"), it feels manipulative. A while ago I was told by members of a separate team that I was writing the core of my javascript application incorrectly. I was following "functional core, imperative shell"[1] and intentionally separating my data from my…

I think that's a case of misguided developers with tunnel vision misusing Fowler's material.

I have never met Fowler and I'm completely speculating here, but I would bet money he is both well-versed in, and a big fan of, the "functional core, imperative shell" concept when it is a good fit.

Devs often get overly dogmatic, and when they do, they often reach for Fowler quotes to back themselves up. But don't blame Fowler for that.

Re: Software Architecture Guide

#194

Post by perlgeek »

crimsonalucard wrote: post #114
perlgeek wrote: post #100

Earlier quoted context omitted.

> A computer is a deterministic system. It is 100% predictable and follows an exact set of rules. Software development is amenable to proof, logic and theory. You don't need to make decisions driven by data or your gut if the problem space can be described by a logical and axiomatic theory. That's true, only if you can assume perfect knowledge about the problems/requirements, the data, the environment, and how (if at…

Yes this is where the "Art" that I described also comes into play. We have no theory that can predict the output of a human brain therefore we can't theoretically derive what requirements a customer will want or change over a span of time. However... There is something sort of new from the academic side that could potentially be a theory that can deal with problem you describe. At a high level the theory looks almost…

What's the relation between category theory and changing requirements? You lost me there...

Re: Software Architecture Guide

#195

Post by charlieflowers »

camgunz wrote: post #184
Ozzie_osman wrote: post #117

Earlier quoted context omitted.

Your point on vocab is so spot on. Simply identifying something as a pattern and naming it is tremendously valuable. Doing it in a way that's packageable and shareable with others is not easy at all.

Agree, but people tend to stop at Fowler and live it as gospel. There is a profound richness in the different ways to think and talk about computers, engineering, and information science, far more wonderous than any one person can catalog. Read SICP, Knuth, Code Complete, Codd. Hell, just YouTube around. If your vocabulary is prescribed by literally one guy in a fedora, you gotta get out there. Might I suggest Joe Ar…

> Agree, but people tend to stop at Fowler and live it as gospel.

I know people do that, and it sucks. But I never got that from Fowler himself.

There are other authors (not naming names) who are pretty dogmatic often. But Fowler seems to genuinely try to capture patterns and techniques in an open-minded way.

It's the abuse of his material that is the problem.

Re: Software Architecture Guide

#196

Post by UK-Al05 »

dvlsg wrote: post #149

His biggest contribution may be the documentation and defining the vocabulary, but when he defines a pattern with a word that has an obvious negative connotation ("anemic"), it feels manipulative. A while ago I was told by members of a separate team that I was writing the core of my javascript application incorrectly. I was following "functional core, imperative shell"[1] and intentionally separating my data from my…

Did you explain that you were following a functional model in your particular app?

Traditional OO (Tatical)DDD does involve creating aggregates with mutating state

Re: Software Architecture Guide

#197

Post by crimsonalucard »

streetcat1 wrote: post #191
crimsonalucard wrote: post #182

Earlier quoted context omitted.

>Absolutely incorrect. I said OO didn't have basis in theory or science. By basis I mean it wasn't derived from theory. Rather it was created as more of an "artistic" endeavor and later it was fit into a framework of an existing theory. You should know almost ANY system can be broken down to fit into an existing theory from a projectile object, to a flying plane, to the weather, to an object oriented programming lang…

She developed the axiomatic theory in a later book: https://mitpress.mit.edu/books/abstraction-and-specification... Were she propose an axiomatic theory for OO interface design. Definitely not artistic. The only thing artistic in OO (as someone who practice it in the last 30 years), is finding the initial set of objects. But you will have this issue with any technique.

>The only thing artistic in OO (as someone who practice it in the last 30 years), is finding the initial set of objects. But you will have this issue with any technique.

OO is highly artistic. It's not just the initial set of objects you decide on, but you have to decide how each and every single object composes and which objects compose. There's multitudes of techniques for how to compose objects and when to compose: Inheritance, dependency injection, Object composition, etc, etc. Within each of these techniques you still have to write custom code, what is the parent, what is the child? What property overrides what? How does the parent use the injected object? etc etc... You are literally designing the system rather than operating within a theoretical framework. It is largely art.

If you operated within the framework of an existing theory you would be able to much better predict the outcome of a system at scale, but because in OO you are creating the system from scratch for almost every application it is largely unpredictable.

In mathematics all theorems flow from your choice of axioms. There is little room for deviation.

Interface is not exclusive to OO. It's a seperate concept. I don't have access to that book so I can't say what she talks about in the book specifically but an interface is not exclusive to OO. The concept exists in mathematics as well which deals more with functions and types rather than objects.

Additionally OO to my knowledge came later after her paper on abstraction. Alan Kay developed OO. Then OO as we use it today came when JAVA and C++ grafted parts of the concept into the framework of procedural languages. This is not deriving a language from theory, it's more of an organic evolution of concepts. This isn't bad, but it's not axiomatic, scientific or theoretical. It is art through and through.

As I said, any system artificially created or not can be fit into the framework of some theory. There is a huge difference though between systems that are designed artistically vs systems that are derived from theoretical knowledge.

Re: Software Architecture Guide

#198

Post by Spearchucker »

jbmsf wrote: post #154
extra_rice wrote: post #131

Earlier quoted context omitted.

I don't understand how anemic domain models are irrelevant now especially in a time where a lot of software practitioners seem to observe domain driven design. In the age of microservices, it is very important to determine clear context boundaries. "Logic lives across multiple services" sounds more like a design smell to me. In this case, changing even very simple business requirements could mean changes in multiple…

I'm definitely guilty of using and promoting anemic models. I find that teams have a hard time deciding whether logic is service or domain or whatever and gravitate towards putting everything in one place if domain objects are allowed to be at all smart. On the other hand, people do well with the rule that logic belongs in procedural layers with clear names and some sort of maximum size/complexity. I also find that t…

First, anemic models work well in service contexts. You can't send a business rule from a web page to a web service as part of a data entity. And so such models have a valid place in the world.

Micro services are still services. As such we always validate data crossing a trust boundary - whether monolith or micro service. The rules to do that validation cannot travel with the data.

So guilt because anemic strikes me as... odd. Modern connected apps aren't written as single-tier Smalltalk apps.

Re: Software Architecture Guide

#199

Post by balfirevic »

neya wrote: post #189
MiyamotoAkira wrote: post #126

Earlier quoted context omitted.

2015: https://www.martinfowler.com/bliki/MonolithFirst.html

I remember this article very well. When it was published, it was too late as we were already following his articles on DDD before that. This is what I meant when I said the authors said we were doing it wrong. This was published after realizing a lot of people who took these authors' advice and went down the DDD path weren't happy and shot themselves in the foot.

There is some ongoing confusion here. Using domain-driven design has no bearing on microservices vs. monolithic architecture.

Re: Software Architecture Guide

#200

Post by charlieflowers »

randomcarbloke wrote: post #10
blub wrote: post #7

Whenever I see yet another article by Martin Fowler, Kent Beck, Robert Martin & co I ask myself - where is the evidence for what they are preaching? What are the graphs based on? What is the evidence behind the proposed rules? These authors are clearly accomplished blog and book writers, but anyone whose software-related accomplishments are not open source or at least well known should have their statements scrutiniz…

Thank you. If I want to design excellent architecture I will crack open SICP and transpose it to the fabric of modern computing. I also take issue with much of what Fowler et al say, but that's another conversation.

I think one of the notions behind the Fowler criticism is something like this: "Early on, a bunch of people got famous as programming thought leaders, but later we all found out there were much deeper, smarter thinkers who didn't get all the buzz."

So the "early" ones might be Fowler, Uncle Bob, Beck, Grady Booch, Evans (DDD), etc.

And the "deeper" ones would be the authors of SICP, or Peter Norvig, or Chris Lattimer.

I can see where this sentiment is coming from, and there's no doubt truth to it.

I'd say SICP is _without a doubt_ deeper and more insightful than most or maybe all of what Fowler has written. From that standpoint, SICP should be more famous than Fowler, but it doesn't seem to be the case. It definitely was not the case 10 years ago.

Still, let's not throw the baby out with the bathwater. Fowler's writing has explained some difficult concepts very clearly. And he chooses topics wisely (but not perfectly in hindsight).

So yes, there are two "tiers" of "experts" about building software. Clearly there is a "tier 1" that is better, more proven, deeper, than Fowler/Martin/et al.

That puts Fowler and some others at tier 2 (or lower, all subjective of course).

That doesn't mean tier 2 is entirely worthless though. IMO far from it.

Post reply on HN