Book Image

Get Your Hands Dirty on Clean Architecture - Second Edition

By : Tom Hombergs
4 (1)
Book Image

Get Your Hands Dirty on Clean Architecture - Second Edition

4 (1)
By: Tom Hombergs

Overview of this book

Building for maintainability is key to keep development costs low (and developers happy). The second edition of "Get Your Hands Dirty on Clean Architecture" is here to equip you with the essential skills and knowledge to build maintainable software. Building upon the success of the first edition, this comprehensive guide explores the drawbacks of conventional layered architecture and highlights the advantages of domain-centric styles such as Robert C. Martin's Clean Architecture and Alistair Cockburn's Hexagonal Architecture. Then, the book dives into hands-on chapters that show you how to manifest a Hexagonal Architecture in actual code. You'll learn in detail about different mapping strategies between the layers of a Hexagonal Architecture and see how to assemble the architecture elements into an application. The later chapters demonstrate how to enforce architecture boundaries, what shortcuts produce what types of technical debt, and how, sometimes, it is a good idea to willingly take on those debts. By the end of this second edition, you'll be armed with a deep understanding of the Hexagonal Architecture style and be ready to create maintainable web applications that save money and time. Whether you're a seasoned developer or a newcomer to the field, "Get Your Hands Dirty on Clean Architecture" will empower you to take your software architecture skills to new heights and build applications that stand the test of time.
Table of Contents (18 chapters)

Why even care about assembly?

Why aren’t we just instantiating the use cases and adapters when and where we need them? Because we want to keep the code dependencies pointed in the right direction. Remember: all dependencies should point inward, toward the domain code of our application, so that the domain code doesn’t have to change when something in the outer layers changes.

If a use case needs to call a persistence adapter and just instantiates it itself, we have created a code dependency in the wrong direction.

This is why we created outgoing port interfaces. The use case only knows the interface and is provided an implementation of this interface at runtime.

A nice side effect of this programming style is that the code we’re creating is much easier to test. If we can pass all objects a class needs into its constructor, we can choose to pass in mocks instead of the real objects, which makes it easy to create an isolated unit test for the class.

So...