Domain-centric vs data-centric approaches to software development
In this post, I’d like to make a comparison of two approaches that prevail in the world of (mostly enterprise) software development: domain-centric and data-centric. If you read my last post (or any other post, quite frankly), you might have noticed I personally gravitate towards the domain-centric approach. Although this article is intended to be an impartial one, keep in mind that my bias can leak out. Domain-centric vs data-centric approaches The main difference between the two approaches is in the way people adhering to them treat software.
Is SQL a good place for business logic?
<TL;DR> No, it isn’t. While SQL is a Turing-complete language and we can use it to encode any business logic we want, placing business (domain) logic into SQL leads to a less maintainable solution comparing to one that uses an OO or functional language. Because of that, I advocate to limit the use of SQL to read-only queries (which can potentially contain business logic, that’s fine) and simple CRUD statements where possible.
SQL vs NoSQL: you do want to have a relational storage by default
The concept of NoSQL databases has been around for a while, but there still are quite a few misunderstandings regarding the topic of relational SQL vs NoSQL databases. In this post, I’d like to clarify the most common misconceptions and discuss the primary use cases for each of them.
Stages of competence: 2 ways of learning
When you enter some field as a novice, there is a lot of stuff you must learn in order to become proficient in it. The learning path can usually be broken down into 4 stages of competence which you can traverse in 2 different ways.
Most valuable software development principles
I’d like to wrap up the "Most valuable software development principles" article series with this post.
Making implicit assumptions explicit
Another software development principle I advocate you follow is making implicit assumptions explicit in your code. Let’s see what that means.
C# and F# approaches to illegal state
You have probably heard of such phrase as “make illegal states unrepresentable” already. Basically, it stands for using some set of techniques for dealing with illegal states in your domain model. In this post, we’ll look at how C# and F# allow us to handle them.
Coded UI vs White
Today, we’ll look at Coded UI and White automation frameworks in terms of building an automated UI test suite for a WPF application. We are going to compare them from different points of view, such as performance, the ease of getting started and maintainability. You will see which of these two frameworks suits what kind of projects and how to make a decision in your particular circumstances.
Automating UI Tests for WPF Applications Pluralsight course
My first course for Pluralsight went live! In it, I talk about techniques and best practices for building a UI test suite for WPF applications. During the course, I go through such topics as: Why we should invest our time into UI tests in the first place. Different types of manual tests and which of them we can automate. The comparison of Coded UI from Microsoft and open source White from TestStack.
Fail Fast principle
The fail fast principle is underlying for many other software development practices. It comes out so often that it’s hard to cover all its appearances in a single article. Nevertheless, that is exactly what I’m going to do here :)
