Hacker News Reader

Comment by throwaway13337 | Hacker News Reader

Surprising this has been written in 2017. It looks like java written a decade ago.

This can be a kind of organizational solution much like microservices to separate concerns. This is important when collaborating with a large amount of people. Clear boundaries and all that.

You pay for those boundaries with a convoluted mess of classes that describe the design pattern rather than the business logic. You end up with AbstractRequestInterfaceFactory type stuff.

Trade offs. Decide when they're worth it.

View on HN

> Surprising this has been written in 2017. It looks like java written a decade ago.

Clean Architecture™ has been around for a while now; I wouldn't be surprised if it was more than a decade already. This post is a guide to an existing concept, not a presentation of something new.

EDIT: This is Uncle Bob, 5 years ago: https://8thlight.com/blog/uncle-bob/2012/08/13/the-clean-arc.... So maybe it's just 5 years old - but then there were similar things (like Hexagonal Architecture) before.

"You pay for those boundaries with a convoluted mess of classes that describe the design pattern rather than the business logic. You end up with AbstractRequestInterfaceFactory type stuff."

I disagree. If a design (call it an architecture) is clean and coherent, it's obvious.

Because obviously a client must send the order to a server, which is protected by a gateway. And of course that gatway validates the client request, and the data coming in. And of course the server must have business rules to validate and process the order. And clearly the business components must call a data access component to persist the orders to a database. Simple, no?

> Simple, no?

what happens when the business rule clashes with the database's constraint implementation, because different people either misinterpreted, or due to incompetence or miscommunication?

I think splitting up sounds great in theory, but in practise, has lots of pitfalls. That's not to say it's not a good idea, but one musn't look at it with rose-tinted glasses.

Well you'd test, which would catch that scenario. Assuming you're not testing and discover it after releasing to production you'd just use your change process.

Either way this is just part of building a system. Refector, re-test and release (or re-release). It's hardly going to be the only bug you find.

Clean architecture is just repackaged DDD. I sympathize with what Bob is trying to do though -- for some reason this stuff often doesn't "click" with many developers until they see it and then it seems "obvious."

I think it's hard to really explain why software should be built like this. This is why architects and senior devs and the like often end up ruling by dictat and simply laying down rules like "messages only in the ACL, no messaging in the domain." The problem that Clean Architecture and DDD are trying to solve are architectural and ultimately organizational problems and these problems are not clear to most developers who are just given a story and told to implement some new feature or story. The only hope is to make these these architectural problems everybody's problem. Spread the pain.

Microservices btw are no escape hatch. Microservices that don't get the essential system boundaries right are in fact going to become a horrible mess. If anything microservices make it more important to think carefully about the boundaries and the interfaces of the system.

>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 are unquestionably the defacto standard for most larger software development projects. Especially since they are intrinsically linked to the containerisation deployment approach which is a modern day concept.

> Microservices are unquestionably the defacto standard

There's a wide world of software out there that you have yet to explore.

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

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

I am very intetested. What makes you think that microservices is current standard? Is there a peer-reviwed study?

I agreed with the first part of your answer a lot more than the second part.

The 'AbstractRequestInterfaceFactory' is something that derives from Java's limitations, not from clean architecture. Clean architecture in Ruby for example is very elegant and does not have unnecessary boiler plate abstraction methods.

More specifically I'd say i only see those kinds of classes together with spring.

Can't remember ever seeing them in plain or modern Java EE code.

Reply on news.ycombinator.com