Software design Articles

So far, my experience with TDD in functional programming is that it is just as beneficial in this paradigm as it is in more traditional ways to think about software.

If you consider yourself to be mature enough, to drop testing pay attention to the minefields you may be leaving behind.

If you are using an Object-Oriented language (writing code in a DSL can change things a bit, it depends on the DSL) you should specify and verify the objects themselves and not how they are implemented.

Slides from the presentation

Using mocks and interactions as drivers for test cases you away from good specifications; always keep in mind that we should only bother about what, not how

Let me try to compile here a list with the books I've read in 2010. I'll also add a very quick review.

Recently a friend discovered this blog. She asked me why do I write so much about Expressive Design. I will try to give some overview of the topic and link to the many articles in this blog about specific points.

Aggregations and compositions are not just collaborations; they are part of the class internal design and should not be exposed; not even to tests.

When a project starts, I don’t care about having a sound and complete architecture. What I do care about is having a reasonable strategy for dealing with architecture decisions.

I’m just too tired of how our industry just does not get the difference between Domain-Driven Design and Object-Orientation.

Probably one the least understood aspects of the architect role is that the software development team **(which the architect is part of)** is itself a very important stakeholder. The architecture has to fulfill requirements from the system users, the project sponsors and developers.

There is nothing wrong with rules of thumb if one keeps in mind that those are there just to help you remember some fundamental principle.

A recurrent question when it comes to real world usage of Domain Models is how to integrate the Presentation and the Business Layer.