Better Software Design with Clean Architecture
fullstackmark.com
Better Software Design with Clean Architecture
1–10 of 141 posts
Re: Better Software Design with Clean Architecture
#2At what point should basic validation be completed?
Re: Better Software Design with Clean Architecture
#3I've seen this a few times before, and it led me to believe that I was stupid. Comments like "...business rules simply don’t know anything at all about the outside world" left me wondering what components that DO know something about the outside world, actually know about the outside world?
Turns out that the answer is a data access component might know where to find a database, and a client app might know where to find a web service. These things were rather obvious to me, so I failed by trying to find loftier answers. Which probably says a lot of about how I think.
Also, the concentric circles did nothing for my way of thinking, as messages are linear - they start from a place, and they end in a place. Thus a stack was a lot easier for me to digest than these concentric circles.
And finally, the ambiguous language. Why should I care that there are enterprise business rules, and application business rules? They're both rules. Rules go into a component in the middle, or business layer.
And thus I found it a lot more useful to think of app design in terms of vertical tiers (hardware abstractions), and layers (software abstractions). Tiers include perimeter, DMZ and corpnet, and layers include (but not limited to) user interface, façade/service gateway, business layer, and data layer. With some cross-cutting concerns like comms, security and operational management (logging, exceptions and so on).
I don't think either is better than the other. It was, however, the first time I really understood that two people can be very knowledgeable about the same thing, and yet speak using a completely different vocabulary.
Re: Better Software Design with Clean Architecture
#4At what point should basic validation be completed?
Superficial validation on things like form fields still occurs up in the UI layer before a Use Case is invoked. Additional validation is likely to happen in the Use Case as well. It's a ubiquitous thing so just like in any other app it should be happening at a few different points but the stuff validated in the Use Case is going to be related to the business rules it's trying to execute.
Re: Better Software Design with Clean Architecture
#5At what point should basic validation be completed?
Superficial validation on things like form fields still occurs up in the UI layer before a Use Case is invoked. Additional validation is likely to happen in the Use Case as well. It's a ubiquitous thing so just like in any other app it should be happening at a few different points but the stuff validated in the Use Case is going to be related to the business rules it's trying to execute.
My approach has always been to validate anything that crosses a trust boundary. This might be user->app; client->gateway; or app->database.
Re: Better Software Design with Clean Architecture
#6Earlier quoted context omitted.
Superficial validation on things like form fields still occurs up in the UI layer before a Use Case is invoked. Additional validation is likely to happen in the Use Case as well. It's a ubiquitous thing so just like in any other app it should be happening at a few different points but the stuff validated in the Use Case is going to be related to the business rules it's trying to execute.
My approach has always been to validate anything that crosses a trust boundary. This might be user->app; client->gateway; or app->database.
This is a great/simple rule to keep in mind.
Re: Better Software Design with Clean Architecture
#7Surprising 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.
Re: Better Software Design with Clean Architecture
#8Surprising 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 Ab…
"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?
Re: Better Software Design with Clean Architecture
#9Surprising 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 Ab…
> 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.
Re: Better Software Design with Clean Architecture
#10Earlier quoted context omitted.
Superficial validation on things like form fields still occurs up in the UI layer before a Use Case is invoked. Additional validation is likely to happen in the Use Case as well. It's a ubiquitous thing so just like in any other app it should be happening at a few different points but the stuff validated in the Use Case is going to be related to the business rules it's trying to execute.
My approach has always been to validate anything that crosses a trust boundary. This might be user->app; client->gateway; or app->database.
>My approach has always been to validate anything that crosses a trust boundary.
That's a good approach unless a validation requires a db call with inner join (for example). This becomes too costly to do it 5 times (for example) just to get something written into db.