Domain-Driven Serverless Design

One reason I really like the serverless architecture approach is being pretty selfish: one has to care only about what matters - the code. Well, I know code is not everything, but as a developer I'm just having more fun coding than scripting infrastructure in YAML or similar. For people like me is the serverless model a dream come true. But how to do serverless without turning the dream into a nightmare?

Don't Share Data among Threads

Distribution of a task among several threads means horizontal scaling - the more computing resources (processors) the less time to work the task out. Sharing data among threads brings the need to synchronize which kills the scaling capability of the computing. How to proceed when shared data are needed?

No Binaries in the Codebase

Binary data shouldn't be a part of the codebase. This is pretty well-known practice. But how to proceed when we do need binaries in our codebase, for instance as test data?

Double Testing

Write your tests once and run them twice - as both unit and integration tests - sounds like a good deal, let's take a look at this practice.

Glass-Box Testing Doesn't Need Mocking

Black-box testing is testing of a component via its API without any knowledge of its implementation details. As the opposite there is the white-box testing. And it about testing implementation, right? Well, no...

Dealing with an Exception is One Thing

Nothing new, but I keep seeing this bad practice around again and again... Let's explain why this is incorrect: boolean save().

Package by Component with Clean Modules in Java

Software architecting is about tradeoffs. Even when the theory is good the implementation details can break it. In this article I try to find the best from two architectural approaches: Package by component and Clean architecture (a variety of Ports and adapters).

Lesson Learned: Principles of Serverless Development

After some time of developing serverless systems (especially on AWS) I take a look back and try to summarize what I have learned so far.

JavaScript async/await in a Loop

Async/await syntax is a great technique how to deal with promises in modern JavaScript. Unfortunately it's not always easy to understand how it works which can lead to strange bugs. Let's investigate one of them.

Use-Case-Driven Testing

Why shouldn't we test the implemetation? How to decouple our tests from the code? What is the reason to add a new test? Why is mocking a code smell? In this article I will try to find answers to those questions.