There are lot of details in the book – clean architecture. The points below just capture what impacted me the most. Hope the points below would nudge you to go through the book yourself.
- The higher the number of dependencies on a class/module, the more legacy it becomes.
- Keep your business logic protected from details like frameworks, databases etc
- Frameworks and databases are details – This implies that the actual business logic shouldn’t be aware of the which framework or database is being used. It is OK to delay this decision. Rather have these layers behind an interface to begin with. e.g. Let the implementation of DAO interfaces provide basic the functionality using basic collection classes. Once you make a decision about the database simply remove the interface implementation with the one specific to the selected database.
- Use access modifiers to control the exposure of your classes/methods. Everything public is surely going to leak out your objects to places they were not supposed to.
- As an architect, it is ok to delay a decision until the decision becomes obvious. An example is choosing the database at the begining of the project. At the start of the project it is almost impossible to know what kind of database would suit the needs of the project. So, put a boundary(interface usually) between your database layer and the layer which uses the database. To start with you can use flat files, in-memory databases etc too. As you keep on adding functionality the choice of database will start becoming obvious. This is much better than starting your development with elastic search because that was the hot thing in the market.
- When code is done right, it requires fraction of human resources to create and maintain.Changes are simple, defects are minimized. Effort is minimized.Functionality is maximized.
- How many layers you had to change for a fix? e.g. if the you had to change the datatype of a column in a database table then did you find yourself making changes in business as well as the controller layer?
- Arrange code layers use-case wise rather than clubbing all use-cases in generic layers like DAOs, services, controllers i.e. have a module(say ordering) and have the DAO, service layers created for that module. Follow same for other modules.