Software design Articles

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.

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

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.

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

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.

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

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.

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

Slides from the presentation

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

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.

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.