Search icon CANCEL
Subscription
0
Cart icon
Your Cart (0 item)
Close icon
You have no products in your basket yet
Save more on your purchases now! discount-offer-chevron-icon
Savings automatically calculated. No voucher code required.
Arrow left icon
Explore Products
Best Sellers
New Releases
Books
Videos
Audiobooks
Learning Hub
Conferences
Free Learning
Arrow right icon
Arrow up icon
GO TO TOP
Get Your Hands Dirty on Clean Architecture

You're reading from   Get Your Hands Dirty on Clean Architecture Build ‘clean' applications with code examples in Java

Arrow left icon
Product type Paperback
Published in Sep 2019
Publisher Packt
ISBN-13 9781839211966
Length 156 pages
Edition 1st Edition
Languages
Arrow right icon
Author (1):
Arrow left icon
Tom Hombergs Tom Hombergs
Author Profile Icon Tom Hombergs
Tom Hombergs
Arrow right icon
View More author details
Toc

Table of Contents (13) Chapters Close

About the Book 1. What's Wrong with Layers? 2. Inverting Dependencies FREE CHAPTER 3. Organizing Code 4. Implementing a Use Case 5. Implementing a Web Adapter 6. Implementing a Persistence Adapter 7. Testing Architecture Elements 8. Mapping Between Boundaries 9. Assembling the Application 10. Enforcing Architecture Boundaries 11. Taking Shortcuts Consciously 12. Deciding on an Architecture Style

It Grows Hard to Test

A common evolution within a layered architecture is that layers are being skipped. We access the Persistence layer directly from the Web layer since we're only manipulating a single field of an Entity, and for that we need not bother the Domain layer, right?

Figure 1.4: Skipping the domain layer tends to scatter domain logic across the code base
Figure 1.4: Skipping the domain layer tends to scatter domain logic across the code base

Again, this feels OK the first couple of times, but it has two drawbacks if it happens often (and it will, once someone has done the first step).

First, we're implementing domain logic in the Web layer, even if it's only manipulating a single field. What if the use case expands in the future? We're most likely going to add more domain logic to the Web layer, mixing responsibilities and spreading essential domain logic all over the application.

Second, in the tests of our Web layer, we not only have to mock away the domain layer, but also the persistence layer. This adds complexity to the unit test. And a complex test setup is the first step toward no tests at all because we don't have time for them.

As the web component grows over time, it may accumulate a lot of dependencies to different persistence components, adding to the test's complexity. At some point, it takes more time for us to understand and mock away the dependencies than to actually write test code.

lock icon The rest of the chapter is locked
Register for a free Packt account to unlock a world of extra content!
A free Packt account unlocks extra newsletters, articles, discounted offers, and much more. Start advancing your knowledge today.
Unlock this book and the full library FREE for 7 days
Get unlimited access to 7000+ expert-authored eBooks and videos courses covering every tech area you can think of
Renews at $19.99/month. Cancel anytime