Writing on software design, architecture, and programming.

All of my long-form thoughts on software design, architecture and programming, collected in chronological order.

Hand-Crafted vs. AI-Assisted Front-ends

Starter templates and code generators are a popular way for developers to get started with a new language or a framework. However, many of them fail to support an efficient and robust development workflow. Most code generators lack production-grade tooling, have limited generation capabilities, and make it hard to share customizations.

Code Shaper – optimizing developer workflows using code generation

Starter templates and code generators are a popular way for developers to get started with a new language or a framework. However, many of them fail to support an efficient and robust development workflow. Most code generators lack production-grade tooling, have limited generation capabilities, and make it hard to share customizations.

JoinJS – An Alternative to Complex ORMs

JoinJS is a JavaScript library to map complex database joins to nested objects. It is a simpler alternative to a full-blown Object-Relation Mapper (ORM), and gives you direct control over your database interactions.

MyBatis vs. Other ORMs

Why I like MyBatis compared to the other ORM solutions that I have tried.

Bullsfirst

Bullsfirst is a sample trading system that demonstrates how technology can be used to solve real world problems. It is a system of medium complexity whose domain is reasonably easy to understand.

7. Domain-Driven Design – Domain Layer

The Domain layer is the heart of the application. It consists of entities, value objects, domain services and domain events.

6. Domain-Driven Design – Layered Architecture

Creating applications that can handle very complex tasks requires separation of concerns. This is where the concept of a Layered Architecture comes in.

5. Domain-Driven Design – Command-Query Separation

Command-Query Separation is an approach to simplify designs and improve performance by separating reads from writes. The approach recommends that every method should either be a Command or a Query, but not both.

4. Domain-Driven Design – Bounded Context

The sheer volume of concepts on a large project can be daunting. We must divide large domains into smaller manageable models, each of which is bounded within a context.

3. Domain-Driven Design – Domain Model

The domain model uses the Ubiquitous Language to provide a rich, visual view of the domain. It primarily consists of entities and their relationships.

2. Domain-Driven Design – Ubiquitous Language

When we design a new system, it's critical that everyone clearly understands the domain and the business problem we're trying to solve. The first step towards this goal is to establish a common language that everyone understands. This language should be rooted in the terminology used by the domain experts and your customers. In DDD, this is known as the Ubiquitous Language because everyone on the team should be using it.

1. Domain-Driven Design

Domain-Driven Design (DDD) is an approach for building high-quality products that meet the needs of a business and its customers. It emphasizes collaboration among domain experts, product managers, designers, engineers, and other disciplines to create a domain model that reflects these needs.