Blog

We had six interns at Omnitech this summer of 2019. For the last several years we've read Clean Code by Bob Martin with each set of interns. This book has proven very successful in opening minds to the value of clean code. This year, we read Clean Architecture by Bob Martin with two of our interns that were back for another summer and eleven of our engineers. We had great discussions and highly recommend this book.

Learn more about our internships.

Value

In the book, Martin shares a story of how a team started out fast, but over time they added more developers, increased costs and decreased productivity. As we discussed this and the rest of the book, we discovered ways to improve and have a more common way of talking about architecture.

We want to have clear boundary lines between components that will allow things to change without causing other areas to need change that we didn't expect. These boundaries act as a "firewall" against change.

We want to defer decisions on details (database, web, I/O) until necessary to avoid re-writing or handling things before they are needed. Deferring choices that are not time-sensitive will help us focus on creating longer-lasting, more stable business value.

We believe that keeping the principles and thoughts from this book in mind will guide us in creating more valuable software solutions.

"If you think good architecture is expensive, try bad architecture."

- Brian Foote and Joseph Yoder

Policy

Entities

• Rules that would exist in the business regardless of if the software exists

• Rules + Data

• Example: Rules to calculate an interest rate

Use Case

• Not UI specific

• Example: Shopping Cart

• When the user adds more than $100 in the cart

• Then they will get free shipping and be notified

Clean Code diagram

There is a lot to learn from Uncle Bob's diagram. We encourage you to read his blog post and the book to learn more.

From https://blog.cleancoder.com/uncle-bob/2016/01/04/ALittleArchitecture.html

Quotes from our engineers

"Not only does the 'correct' architecture depend on the project, but it can change at various points in the project's life."

"MVC is not an architecture, just a pattern. A well-designed architecture should mimic the purpose of the application."

"Architecture cannot be an afterthought. Referring to the first few chapters that discussed how brutally expensive bad architecture is."

"The section on programming paradigms (Structural, OO, Functional) blew my mind, in particular, the chapter on Object-Oriented. I feel like I now finally understand the benefits that OO gives us and how to use it effectively."

"Delay decisions of database, web, and other details."

"Almost always code against interfaces, not implementations."

"Your code organization should be based on the 'actors' who would be needing changes."

"Architecture is one of those abstract things that is hard to understand – but every project has an architecture, even if it’s a bad one. Before this book, I considered architecture to be one of function – It’s what helps the system do what it needs to do in order to meet the business goals. While that is true, it’s also naïve. Architecture is in place to aid development, deployment, operation, and maintenance of a system. It doesn’t control what the system does; it supports it."

"Our job, as architects, is to break the system down into small components and control the dependencies of those components in such a way that the system becomes flexible and easy to extend. This requires diligence…"

"The architecture of our applications will always be a second class citizen to their functionality in terms of urgency. Therefore as engineers, we must advocate for the architecture, maintainability, and testability of the code. As architectural quality declines, so too does the developability. Architecture is always important, but rarely will it be urgent."

SD Code Camp 2019

Kevin and John will be presenting for us at Omnitech, then at SD Code Camp on November 8, 2019. We hope to see you there and have a discussion about it.

https://2019.southdakotacodecamp.com/schedule/sessions/clean-architecture/

Applying what we've learned at Omnitech

We've already noticed our discussions changing the way we talk and think about building applications. We've shared these ideas at a Lunch and Learn, but have more work to do to pool our experience to discover the best approaches.

We've had a new project where the ideas of Clean Architecture have been applied in code, and it has been constructive to see the theory take shape. This is different from our standard tiered (MVC/Services/Database) and Database centric approach. Instead, we are trying to use the layers as described in Clean Architecture. Since it's a .NET MVC application control enters into the app through Controllers. The Controllers pass along data to Use Cases. These Use Cases perform the business logic by interfacing with Entities (business objects) and Repositories (gateways to the Database). Once the Use Cases are done they transfer data to Presenters that get responses ready for the Controllers to send back.

In architecting the project this way, the emphasis is on the use cases (i.e., the business logic) rather than the database. Furthermore, every layer is isolated and boundaries between the layers are managed by utilizing interfaces and passing request and response objects. This keeps the overall structure of the project focused on the business logic and minimizes the impact of changes in any one particular layer.

There is still much left to learn, and this approach is by no means "complete." It will undoubtedly evolve as we continue to use it and see what the benefits and limitations are, but we plan to use it as a project template going forward and look for ways to streamline this approach that will help us fall "into the pit of success."

A few resources for continued learning

• https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html
• https://blog.cleancoder.com/uncle-bob/2016/01/04/ALittleArchitecture.html
• https://jeffreypalermo.com/2013/08/onion-architecture-part-4-after-four-years/
• https://fullstackmark.com/post/18/building-aspnet-core-web-apis-with-clean-architecture
• https://www.weeklydevtips.com
• https://github.com/ardalis/CleanArchitecture
• https://youtu.be/IAcxetnsiCQ Ian Cooper at NDC 2019
• https://stackoverflow.com/questions/10061913/application-architecture-in-practice-uncle-bob
• https://www.codingblocks.net/ - Coding Blocks Podcast, they have several conversations about the book

Conclusion

We've learned with Clean Architecture that there are many things we can apply to increase the success of our projects. A successful project is more than creating features, but also creating a system of code that will be able to change as needed with less effort.

We believe that coupling this with automated testing, reducing Technical Debt and applying "the only way to go fast, is to go well" (pg xviii, Bob Martin) will enable us to improve continually.

We will continue to learn and strive to create the best quality solutions in the most efficient way that we can for our clients.