A Java Geek weekly 114

If you attend conferences or read technical articles, you could think that microservices are the correct and only way to build a system at the moment. Despite some pushback from cooler heads, the default architecture is microservices. In this post, I’d like to argue why it’s wrong. I’ll first get back to the origin of microservices and the fundamental reason to use them. Then, I’ll describe why microservices don’t fit most organizations' structures. Afterward, I’ll move to detail the root problem to solve. I’ll conclude by proposing an alternative, less-risky approach.

What we have built here is essentially a micro-implementation of a classic architectural pattern known as Functional Core, Imperative Shell.

Logic vs language: how a Turkish alphabet bug played a years-long game of hide-and-seek inside the Kotlin compiler.

1. CLAUDE.md is for onboarding Claude into your codebase. It should define your project’s WHY, WHAT, and HOW.
2. Less (instructions) is more. While you shouldn’t omit necessary instructions, you should include as few instructions as reasonably possible in the file.
3. Keep the contents of your CLAUDE.md concise and universally applicable.
4. Use Progressive Disclosure - don’t tell Claude all the information you could possibly want it to know. Rather, tell it how to find important information so that it can find and use it, but only when it needs to to avoid bloating your context window or instruction count.
5. Claude is not a linter. Use linters and code formatters, and use other features like Hooks and Slash Commands as necessary.
6. CLAUDE.md is the highest leverage point of the harness, so avoid auto-generating it. You should carefully craft its contents for best results.

Sustainable architectural health depends on how well revenue goals, product needs, and technology strategy align.

• When writing integration tests for Spring applications, align them with your functional decomposition approach, because that means you will test more cohesive elements of your code base.
• That orientation produces tests better aligned with the "Four Pillars of a Good Test" (from "Unit Testing—Principles, Practices, and Patterns") than the traditional, horizontally-sliced approach.
• Spring Modulith’s https://docs.spring.io/spring-modulith/reference/testing.html@ApplicationModuleTest^] annotation provides first-class support for these kinds of integration tests.

For organizations seeking tailored AI solutions, Mistral AI offers custom model training services to fine-tune or fully adapt our models to your specific needs. Whether optimizing for domain-specific tasks, enhancing performance on proprietary datasets, or deploying models in unique environments, our team collaborates with you to build AI systems that align with your goals. For enterprise-grade deployments, custom training ensures your AI solution delivers maximum impact securely, efficiently, and at scale.

Rule of three ("Three strikes and you refactor") is a code refactoring rule of thumb to decide when similar pieces of code should be refactored to avoid duplication. It states that two instances of similar code do not require refactoring, but when similar code is used three times, it should be extracted into a new procedure. […​]

Duplication is considered a bad practice in programming because it makes the code harder to maintain. When the rule encoded in a replicated piece of code changes, whoever maintains the code will have to change it in all places correctly.

However, choosing an appropriate design to avoid duplication might benefit from more examples to see patterns in. Attempting premature refactoring risks selecting a wrong abstraction, which can result in worse code as new requirements emerge[2] and will eventually need to be refactored again.

The rule implies that the cost of maintenance outweighs the cost of refactoring and potential bad design when there are three copies, and may or may not if there are only two copies.