Clean architecture for Enterprise SPA applications

As front-end developers, we see encouragement to practice test automation in our craft. In the coaching of back-end engineering, I greatly appreciate the teaching of Steve Smith(ardalis), a thought leader in domain-driven design, enterprise application development, and pragmatic architecture. He provides a practical perspective on agile engineering practices and architecture. He, however, tends to focus on the enterprise .NET community.

In a previous life, I worked in a financial business domain that thrived using domain-driven design(DDD) practices. It worked because that financial domain had complex business logic all over the place and DDD helped the team keep alignment. DDD can feel like overkill on many smaller business applications. I have felt that the “Clean Architecture” teaching from Steve Smith has provided my teams with a middle ground that helps us organize our code for business logic test automation. As I write this post this week, I have a project shifting databases and cloud storage strategies. I love seeing that the business logic modules still have passing unit tests. Further, I used a suite of integration tests to ensure the “core” logic integrated with the query and store operations. This has helped me focus my attention through the sprint.

I still remain curious how these ideas can help front-end JavaScript teams. I found a few posts to explore these ideas. I believe that developers should focus their attention on non-trivial business logic. How do we do this well?

In general, the “clean architecture” pattern has the following benefits:

• Modularity and Separation of Concerns: Clean architecture encourages teams to encapsulate rich business logic into testable service classes, handlers, or use cases. The architecture provides a home for infrastructure-level code. For business applications with a low to moderate amount of business logic, it provides enough structure to reason about your business domain and keep things organized.

• Testability: By design, a good “core” module should have minimal dependencies on infrastructure code. Infrastructure code can include things like storing data, doing queries for data, sending email, or connecting to an AI service. Under test conditions, you want to maintain a suite of tests that’s fast. Using interfaces or abstract classes, you can make your dependencies return data that’s required for your unit test.

• Testability encourages smarter class design: Let’s say you are testing a class named “Foo” and it has 7 different dependencies. Those dependencies will be announced in the constructor of the class under test. As you write the unit test and try to construct “Foo”, you think to yourself that the class feels hard to test because it requires the setup of too many things. As teams become more aware of class complexity and the number of dependencies, they tend to start making classes with smaller sets of responsibilities and dependencies. This encourages the habits of smaller class responsibility. Naming things is hard at times. A “test-first” mindset encourages the development team to think about their business logic service methods from a clarity, consistency, and usability point of view.

• A different approach to frontend architecture: In this post, William outlines high level motivations for implementing clean architecture into larger front-end applications. Architecture is all about trade-offs. The team should consider clean architecture an investment to remain agile at later stages. I appreciate how he comments on this topic from the perspective of React, Vue, and Svelte.

• Approach to Clean Architecture in Angular Applications: In this blog post, the author outlines the major concepts and file organization he used in some of his Angular projects. It’s a nice “keep it simple” pitch for the pattern.

• Clean Architecture on Frontend: This article by Alex Bespoyasov provides the most detailed exploration of the pattern. You will find links to video talk from the author, slides, and detailed discussion. The author brings up some of the challenges of implementing the pattern. You can also find a demo repository of his layout here on github.