Live data from Hacker News

Better Software Design with Clean Architecture

fullstackmark.com

91–100 of 141 posts

Re: Better Software Design with Clean Architecture

#91
post #16

Earlier quoted context omitted.

> Surprising this has been written in 2017. It looks like java written a decade ago. Because good architecture has somehow evolved? > This can be a kind of organizational solution much like microservices to separate concerns. This is orthogonal to microservices. And microservices aint but one model of creating applications, not "THE 2017 model".

> Because good architecture has somehow evolved? Of course. Every year gives us greater insight into what approaches work and don't work. Which is why we have seen Java technologies like EJB, JCA, JTA, OSGI, JSP etc generally fall by the wayside in favour of less convoluted and less architecturally heavy approaches. > And microservices aint but one model of creating applications, not "THE 2017 model". Microservices a…

>Microservices are unquestionably the defacto standard for most larger software development projects.

In the HN echo chamber maybe -- but not sure even there.

Re: Better Software Design with Clean Architecture

#92
post #90
post #86

I had been quite skeptical of Clean Architecture when I first came across it. I don't find Uncle Bob's post on it particularly insightful; for me it's not vocational enough. Then a few years ago I had to maintain a software stack written by contractors from Pivotal ( https://pivotal.io/ ) in a Clean Architecture style - it was truly a revelation for me; akin to that "aha" moment of fully grokking homoiconicity in LIS…

That codebase sounds interesting, is there a change some parts of it were open sourced?

Unfortunately no :(

Re: Better Software Design with Clean Architecture

#93

Oh look, more kludgy over-designed enterprise gumf. When are people going to learn that if you just start with the entry point with granular components, letting each define the interface for its dependencies, you get a much nicer, looser, more flexible structure than these enterprise "patterns" that ultimately all just turn into a big ball of mud? Stop pretending you can design codebases.

It's just human nature. People come up with geocentric ideas for everything. It's certainly not limited to software designers or even particular modes of software design. Ever talk to Semantic Web people? Or, ontologists? People tend to naturally assume that there is one set of "Enterprise Entities". Heck, it even took physicists a long time to come up with general relativity. And, they only did it after their absolute models broke down.

So, yes, each granular component should have its own perspective of "the Enterprise". But, contexts can be very different. For a simple example, a "car" may have completely different interface depending on if its user is a "car designer", "car assembler", "car salesperson", "car driver", etc. So, someone trying to define a universal interface for a car will make themselves and their teams crazy. Worse, the idea of "a car" will change through time, so even perfect interfaces will have to change.

This isn't limited to object oriented design, by the way. Functional programming paradigms have the same issues.

Re: Better Software Design with Clean Architecture

#94
post #18
post #15

Earlier quoted context omitted.

"presence of sql escape characters" - isn't a business rule. That's technical. Range acceptance - could defiantly be a business rule. Cross-field consistency - Could also be a business rule. I implement these rules both sides. Ideally i don't want an invalid command sent off in the first place. I also don't want badly implemented UI corrupting my business data. This way i can provide instant feedback to the user, and…

"I implement these rules both sides" ... and the maintenance overhead?

This is stuff like there is JavaScript regex that checks for an @ character in an email and in the back end code. There is no reason to not do both.

Re: Better Software Design with Clean Architecture

#95

Oh look, more kludgy over-designed enterprise gumf. When are people going to learn that if you just start with the entry point with granular components, letting each define the interface for its dependencies, you get a much nicer, looser, more flexible structure than these enterprise "patterns" that ultimately all just turn into a big ball of mud? Stop pretending you can design codebases.

People forgot at some point that design patterns are for solving problems. The key being that you should only be solving problems you actually have, and stop making up imaginary problems in your head before you even start coding. My code is typically some dumb data objects, static functions to apply rules to that data, and a bunch of interfaces for abstracting external dependencies. The code that ties everything toge…

What are the disadvantages?

Re: Better Software Design with Clean Architecture

#96

You know someone is certified when you have to scroll code sideways because the names don't fit the screen. I thought we already agreed that process is the opposite of progress? I mean come on, RequestCourseRegistrationInteractor, who are you trying to impress here? These processes were designed to turn humans into machines; to decrease the dependence on creativity and skill at the cost of additional effort and compl…

I think you are opposing it for the wrong reason.

There should not be a lot of room for creativity when implementing specific business rules. The goal should be clarity and readability.

These convoluted patterns obscure the logic and confuse the reader with their pointless abstractions.

Re: Better Software Design with Clean Architecture

#97
post #63

Oh look, more kludgy over-designed enterprise gumf. When are people going to learn that if you just start with the entry point with granular components, letting each define the interface for its dependencies, you get a much nicer, looser, more flexible structure than these enterprise "patterns" that ultimately all just turn into a big ball of mud? Stop pretending you can design codebases.

Which is essentially what this is.

My objection to Uncle Bob is that it seems really heavy on process, with lots of indirection via adapters, abstract base classes, etc.

I get that they're useful for taming a certain amount and kind of complexity, but it's not clear to me that it's always going to be apparent at the beginning that it's going to need taming in that specific way. I've found that starting with the concrete cases, I only sometimes have to go up a level of abstraction and indirection. Conversely, I've built the wrong abstraction many times by starting too high.

I don't read or write Java so I'm sure I'm missing a lot of context. That's what I'm looking for. Uncle Bob's an eloquent speaker and his talks make a lot of sense, but I have trouble reconciling that with the code samples I see.

Re: Better Software Design with Clean Architecture

#98

Oh look, more kludgy over-designed enterprise gumf. When are people going to learn that if you just start with the entry point with granular components, letting each define the interface for its dependencies, you get a much nicer, looser, more flexible structure than these enterprise "patterns" that ultimately all just turn into a big ball of mud? Stop pretending you can design codebases.

I find your extreme as problematic as the article's.

What you describe, at least in my experience, more often than not leads to a big ball of mud as easily as the methodology in the article.

Software can be designed. It's just there's little appetite for an actual rigorous design process in this industry. Instead there is a lot of bandwagoning and looking for one size fits all solutions (like the article's), mixed thoroughly with people who haven't ever really grown beyond thinking of textbook CS as the solution to every problem.

Re: Better Software Design with Clean Architecture

#99
post #36

Earlier quoted context omitted.

How did you decide that the registration is a property of the student and not the course?

I've come to avoid OO and use only freestanding functions where possible mostly because of this problem. So often it ends up in a syntactic distinction that is absolutely meaningless otherwise. I use some OO to make abstract datatypes in languages that are inherently OO, but I think the explicit virtual table approach in C or the type classes approach in Haskell are much cleaner. Lately I had to make a REST API which…

Some would call your procedural interfaces services and map your REST API directly to publicly available service methods.

Re: Better Software Design with Clean Architecture

#100

Earlier quoted context omitted.

People forgot at some point that design patterns are for solving problems. The key being that you should only be solving problems you actually have, and stop making up imaginary problems in your head before you even start coding. My code is typically some dumb data objects, static functions to apply rules to that data, and a bunch of interfaces for abstracting external dependencies. The code that ties everything toge…

What kind of design is this? Is there a name for it? I'd like to read more (both out of interest and being skeptical of how this scales)

I've seen that particular type of method/function be called a use case, interactor, or service object.
Post reply on HN