In our previous article The Spring Framework is for Nazis, we established that code annotations are the exact same thing as your application architecture getting fucked in the butt. Now since we at The Woke Programmer are very inclusive and forward thinking, we had to ask ourselves: “What if your architecture really likes it from behind?”. This being a valid point, we investigated further into methods to help it become more open about its sexual preferences and offer you ways to celebrate your diversity.

Break tradition

There are a lot of old men out there telling you what you’re trying to do is wrong. They come up with retarded bullshit like strictly separating domain logic from infrastructure code. Fuck these morons, it’s 2019 and if those two things want to be together, who are you to judge? Add that Spring MVC to your core module right now and let it embrace it with the warm touch of annotations.

Focus on double penetration

Yes, the spring framework by itself is already pretty invasive and potent enough to completely fuck your architecture. But now it’s time to step up the game and invite his best friend over for a threesome: Hibernate.

Hibernate has the unique ability of adding pretty much the same annotations to your project that are already there due to Spring. This is called Persistence Layer, because it persists to fuck you on another layer.

Try something new

New annotations get invented almost every day. So make sure that they smoothly slide into the rectum of your architecture by applying this convenient trick – just replace every occurrence of

<dependency> <groupId>...</groupId> <artifactId>...</artifactId> <version>5.1.8</version> </dependency>

with this

<dependency> <groupId>...</groupId> <artifactId>...</artifactId> <version>LATEST</version> </dependency>

in your pom.xml and Maven will deliver fresh annotations directly to your application’s ass.

Test your limits

There’s a secret area in every project free of rules and limitations, where you can break taboos and get as dirty as you can imagine: the test section. But don’t get confused by words – those are not tests, those are challenges. Challenges to fit as many different annotations into one single class file as possible. The combined forces of JUnit, Spring and Mockito can take things to a whole new level. And don’t let quality hold you back – remember, it’s just test code.

Stay safe

So you decided to allow your architecture to have some fun, but are now worried about things like STDs (Seriously Tight Dependencies)? Easy. Just use a condom. Instead of letting the framework penetrate your business logic directly

public final class MakeDepositUseCase { @RequestMapping(value = "/makedeposit", method = RequestMethod.POST) public void makeDeposit(@RequestParam("amount") final int amount) { ... } }

you just wrap it up in a thin layer of artificial plastic that no-one really wants:

public final class DepositController { @Autowired private final MakeDepositUseCase makeDepositUseCase; @RequestMapping(value = "/makedeposit", method = RequestMethod.POST) public void callTheActualUseCase(@RequestParam("amount") final int amount) { makeDepositUseCase.makeDeposit(amount); } }

Don’t forget to craft one of these with every new feature you add to your application. After all, what could possibly go wrong?

Go beyond

Why stop at annotations? If you want to get your business logic fucked by unnecessary dependencies, there’s a whole world of options. Get creative. Need a REST client because of microservices? – just add REST-assured to your horny project and rest assured that the enormous tail of groovy dependencies will be exactly what it is looking for.