4 ms·
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 an
by UK-AL 9y ago
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.
- the_arun 9y agoThanks. I think I see this reference in the article - http://jeffreypalermo.com/blog/the-onion-architecture-part-1/ 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 :)
- UK-AL 9y agoI don't why it would be insecure...
- the_arun 9y agoI 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.,
- UK-AL 9y agoWell those layers are really protecting the domain.