Test automation framework architecture. Part 1 - No architecture

Most of the "UI test automation" tutorials I have seen describe the Test Automation Solution where Selenium Web Driver is used directly from test methods and no additional abstraction layer exists. This "architectural pattern" is so ubiquities, that I decided to describe this as well.
I think, we can call this "architectural pattern" as No architecture. The structure of test automation solution created with No architecturepattern presented (in a very rough way) on the picture below:
Such test automation solution usually consists of some amount of test classes, each containing some number of test methods. All orchestration of interaction with System Under Test (SUT) is done either (using JUnit terms) in setUp and tearDown methods, or test methods themelves. Tool, whatever it is - Selenium, RestAssured, Selenide - called directly in test methods.
Such approach is industy well known anti-pattern. However, in some cases, it may be ok to use. There're some…
I think, we can call this "architectural pattern" as No architecture. The structure of test automation solution created with No architecturepattern presented (in a very rough way) on the picture below:
Such test automation solution usually consists of some amount of test classes, each containing some number of test methods. All orchestration of interaction with System Under Test (SUT) is done either (using JUnit terms) in setUp and tearDown methods, or test methods themelves. Tool, whatever it is - Selenium, RestAssured, Selenide - called directly in test methods.
Such approach is industy well known anti-pattern. However, in some cases, it may be ok to use. There're some…