A lot of these architectures assumes DDD. (I'm not sure if clean architecture does)
Domain driven design. You model you business problem using plain objects and methods. The domain should do nothing else other than modeling the domain, and solving the business problem you app is designed to solve. It should be persistence ignorant.
Then everything else simply has adapters for interfacing with the domain. Including a persistence adapter.
This is basically ports & adapters, and a lot of these architectures are basically variations on that.
Thanks. I think I see this reference in the article - http://jeffreypalermo.com/blog/the-onion-architecture-part-1... which explains why DB should be outside. It makes sense in the services and NoSQL world, but i would not put at the edge. Feels like we are doing something wrong & insecure. It could be my mindset issue :)
I mean from block diagram perspective, we are always used to keep data in the center secured by all other layers. But that pattern is changing in the days of AWS & Google Cloud, where data can be anywhere. If data is a service, it doesn't matter where it is located. But if Data is a layer within the application, we need to surround it by protective layers such as app, gateway etc.,
Domain driven design. You model you business problem using plain objects and methods. The domain should do nothing else other than modeling the domain, and solving the business problem you app is designed to solve. It should be persistence ignorant.
Then everything else simply has adapters for interfacing with the domain. Including a persistence adapter.
This is basically ports & adapters, and a lot of these architectures are basically variations on that.