1

I watched a video series from Uncle Bob on Clean Code. He makes a few points on architecture which I both agree with but I believe could have clarification.

From Uncle Bob:

  1. The Interactor is connected using Boundaries
  2. Architecture should be fluid
  3. Trust your team

My Understanding:

  1. Use protocols (depending on language)
  2. I should feel free to write and change my code as needed, when needed
  3. For internal only applications, we have full control and we work together

However, if I don't need protocols then can I start by not using protocols and when it's necessary to use them I convert my classes/object to conform to protocols. My main concern is the development overhead of protocol (albeit small) is not beneficial until there is >1 user of the Interactor. And 99% of the time in my apps there generally is only one Controller/Presenter connecting to my Interactor.

Further, does all that above also apply to using public/private? I generally use private when I want to convey that function shouldn't be called. Generally because it's a helper, it's dangerous to call it directly, etc. But why would I spend the effort making everything private just because?

14
  • 1
    Can you provide a citation/reference for "Architecture should be fluid" please? Jul 9, 2020 at 18:43
  • I've never read "Clean Code", but I am familiar with Uncle Bob. There's very little architecture you need to write if you are using a container project, kind of like what Spring is for Java. Someone else has done all the hard work, and you only need to specify what the dependencies are. The container will take care of all the hard work of aligning them. Jul 9, 2020 at 20:35
  • 1
    @BerinLoritsch I've read various articles on his website, but I recently watch all 6 lessons / 2 days of Clean Code. You can search the videos with "Clean Code - Uncle Bob / Lesson 1". Jul 9, 2020 at 22:35
  • @RobertHarvey His video has a slide with "A good architecture allow major decisions to be deferred". cleancoder.com has a quote "A good architect defers the decision about how the system will be deployed until the last responsible moment.". Why would you need a citation to make a comment on the question? Jul 9, 2020 at 22:39
  • 1
    Because I don't really understand the context of the statement "Architecture should be fluid." Jul 9, 2020 at 23:11

2 Answers 2

1

In this article I make the case that Clean Architecture is unsuited for basically most, if not all circumstances. It is in any case unsuited for object-oriented projects, because it is at it's core simply not object-oriented.

You are not imagining it, it is not just overkill and over-engineering, it is positively harmful to have artificial (i.e. technical, i.e. non-domain) boundaries inside your application, especially if you won't need it at all.

The architecture should be fluid? I have no idea what that is supposed to mean. The architecture should reflect the domain! That's it. In your design, you have a chance to communicate with future readers. What would you want to tell them? Do you want to tell them about the domain, or do you want to tell them about your l33t architecture skillz? Maybe you want the latter :), but your readers might appreciate the former.

3
  • 1
    I did read a lot of your article. My understanding of Clean Code / Architecture is not a concrete methodology and I don't see it directly related to OOP. While a lot of Uncle Bob's examples are Java, his explanations or language agnostic. He's talking about a way to separate the development of the code. How do you tell people about your domain without architecture? Do you use an over abundance of comments, because then I recommend clean code. Jul 13, 2020 at 18:43
  • 1
    "The architecture should be fluid? I have no idea what that is supposed to mean. The architecture should reflect the domain!" You're agreeing with Uncle Bob. The main characteristic of a fluid is that it takes the shape of its container. That is a quite excellent analogy for architecture reflecting the domain and not having a preset rigid structure.
    – Flater
    Aug 12, 2021 at 7:21
  • We might say the same words, but it's not the same. When I say the architecture should reflect the domain, I mean the whole thing must be organized to convey domain-relevant information. You can't have technical boundaries and still claim domain-relevance. How is it domain-relevant that you have DTOs and separated UseCases and "Gateways"? How can you use a layered architecture if the domain is not layered that way? Aug 12, 2021 at 7:47
0

However, if I don't need protocols then can I start by not using protocols and when it's necessary to use them I convert my classes/object to conform to protocols.

Beware the old adage of painting yourself into a corner. This is a classic tale of how bad practice development often perpetuates itself because a dev team that didn't want to pre-empt good practice generally remains unwilling in the future to then spend even more effort (because now it's a bigger issue/job) to introduce that good practice.

It is much easier for code cleanliness to drop than it is to increase it.

However, that doesn't mean you need to do everything from the get go either. On the other side of the spectrum sits YAGNI, urging you to not develop things you don't yet need.

There is a careful balance to be struck here. And it's nigh impossible to strike that balance perfectly. So instead ask yourself which way you'd like to err. Would you rather save some effort today at the risk of increased (and more difficult) effort in the future? Or would you rather invest effort early in the expectation that it will pay back dividends in the future?

I can't make that decision for you, but as a consultant who has been brought in to several companies whose development culture had gone down the drain and were no longer capable of delivering projects; I can only offer the consideration that it's very alluring to put off the boring work of clean coding practices, and urge you to really consider if it's the best choice and not just the easiest choice.

My main concern is the development overhead of protocol (albeit small) is not beneficial until there is >1 user of the Interactor.

When an application is well liked and does its job well, people will inevitably try to do more and more with it. Eventually, the codebase will buckle under that increased usage.

Clean coding practices not only help with redistributing that added pressure, but makes it significantly easier to upgrade or scale up parts of your application.

Again, I can't tell you that you must invest in clean coding practices. Exceptions do exist. But the people who end up regretting their decision are by a large margin the ones who underinvested in clean coding practices, not the ones who overinvested.

To put it differently: would you rather have paid for health/fire insurance and risk never ended up putting in a claim; or would you rather not pay for health/fire insurance and risk the health/renovation bill when something does happen?

And 99% of the time in my apps there generally is only one Controller/Presenter connecting to my Interactor.

As far as logic is concerned, something either happens or it doesn't. There is no meaningful difference based on how often something happens. As long as there is a non-zero amount of use cases with more than one controller/presenter connecting to your interactor, you have to work out the logic for that non-zero amount of use cases.

And again, I can't tell you you must adhere to whatever practice you're being suggested. All I can offer is to really think through if it's going to work for you, and offer the reminder that humans often undervalue clean coding practice because it is boring and doesn't immediately reward you for it. The rewards are deferred until the future, when inevitably changes/upgrades/scaling/bugs happen.

But why would I spend the effort making everything private just because?

Think of it like the doors in a company. Should they be unlocked or locked by default? Well, that depends on certain factors.

If security and privacy is paramount (e.g. banking, prison, ...), then a company will opt to keep their doors shut and use e.g. badge systems for employees. But if the company wants to promote foot traffic, such as most shops, it's much better to have open doors.

In software development terms, you want to minimize the foot traffic to reduce complexity. Because of that, you take time to think about exactly who needs to be where, and you'd rather not give people access to places they don't need access to. Bob the accountant needs access to the office but doesn't need to be in the security office's armory, so to reduce the odds of abuse, whether willful or accidental, it's better to lock the armory door and not give Bob the ability to open that door. Even if he doesn't have ill intent, Bob is still a wildcard when left unsupervised with things that he is not trained for.

This is why the suggestion is to keep things private unless there is a public need for them. It ensures that outside actors can't just waltz in and start meddling with things that should not be meddled with. Much like how every person who wants to access the armory will be individually vetted, every time you make something public, you need to really consider whether this should be made public or not.

3
  • I'm not really sure what your position is, but after reading your answer I think my original position is more validated. I fairly know how to use clean code and I now believe even more that I should only write what's needed and add in all the common architecture only as needed. Aug 15, 2021 at 19:20
  • @MichaelOzeryansky: As far as my position goes, there is no side to pick. I disagree both with those who preach bad practice shortcuts and those who preach overzealous good practice. This isn't a matter of right or wrong, it's a matter of the right approach for the right situation. But be aware that architecture is a backbone, and it's really hard to make meaningful changes to a backbone when it is already supporting a codebase. Deciding halfway to change your approach because now you've reached a limit that you hadn't before leads to much more work and headaches than preparing in advance.
    – Flater
    Aug 17, 2021 at 7:35
  • I see. Far too many teams I work with seem to be afraid of changing their code, limiting their scope of work to as few functions or files as possible. Time and time again this just leads to code bloat in the long term and the reason appears only that people are afraid and no technical reason. I think if a change is needed, then make that change, doesn't matter if it touches 1000 files. Aug 21, 2021 at 17:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.