Archive for the ‘architecture’ Category

Domain models and the database schema

May 24th, 2013


A domain model does not have to look like the database schema.

They can resemble each other but they don’t have to.


A domain model is for handling domain problems while a database is for storing and retrieving data. Let each tool do what it is best at; a hammer for nails and a screw driver for screws.

>Time estimation and business objects, CRUDSLM

March 20th, 2009


A small rule I have while estimating time or looking into a system is to run CRUDSLM against all business objects and possibly all database tables.

I make sure that every business object has one tick in each C, R, U and D.  This is the normal case and by doing this I guard myself against forgetting something.  There are times when things aren’t updated and even not deleted but then I know this and can argue for it.
It is a fast exercise and I usually run it only once against every business object and once against every database table.

For time estimation I extend the CRUD with SLM where the letters are Search, List and Manipulate respectively.  Many times, especially with the main business objects, they are Listed and Searched.  Then for reports, imports and exports they have to be Manipulated too.

I have many times found out that Delete is missing.

>Exception and how to classify

November 2nd, 2008


One way to classify the custom exceptions thrown by an application is by how fatal they are.  An Eric Lippert has a good idea which somewhat rhymes with my own thoughts of 3 levels of importance.

>The simplest possible solution, but not simpler than that

January 22nd, 2008

>This message will be repeated in english.

När man inom Agile pratar om den enklaste metoden menar man inte den lösning man först kommer på eller den som går snabbast att implementera.
Med enklast innebär den lösning som löser uppgiften med minst extra information och avsteg från befintligt mönster.

Detta kan tarva en förklaring.
Med minst extra information menas möten, dokumentation och implicit och explicit kunnande. Om lösningen följer gängse mönster behövs antagligen ingen dokumentation, varken som explicita dokument eller inline-kommentarer. Om lösningen är “rätt” krävs mindre möten, diskussioner, dokumentation, rådfrågningar och redogörelser.

Enklast är inte nödvändigtvis den lösning som kräver minst tankearbete eller minst jobb.

För att vara ärlig talar jag inte för hela den agila rörelsen. Texten ovan är min tolkning av begreppen, metoden, livet, universum och allting.

When the agile development movement talks about the simplest solution; they do not mean the first solution that pops up in the head or is fastest to implement.
Simplest means the solution that solves the problem with least extra information and sidesteps from the chosen/optimal path.

This might demand an explanation.
With least extra information means meetings, documenation, implicit and explicit knowledge. If the solution follows the chosen path, colour and rythm of other well written parts of the solution; it probably doesn’t need documentation, neither as explicit documents nor as inline comments. The “right” solution requires less meetings, discussions, documentations, questions and answers.

The simplest solution it not neccessarily the solution that requires the least amount of thoughts or work.

To be honest I cannot say I speak for the whole agile movement. The text above is my view of the terms, the method, life, universe and everything.

>Central objects in the domain model

January 4th, 2008

>This message will be repeated in english.

Bli inte förvånad att det centrala på en fabrik inte är det centrala när domänen modelleras.
I kvalitetssäkringen av en rörfabrik är inte nödvändigtvis rören som är centrala utan istället alla mätvärden; och inte ens dem utan den lilla biten som säger om mätningen är godkänd eller inte.

Do not get surprised when the central object in a factory is not the central object in the domain model.
When creating a system for quality assurance in a tube factory it is not neccessarily the tubes that are central in the domain model but the measurements; and not even them but the small bit that tells if the measrumenent is approved or not.

>Fail At Once

October 19th, 2007

>This message will be repeated in english.

Automatiska tester i all ära men hade det inte varit bättre om man inte hade behövt testa alls?

Jag kommer komma tillbaka i ämnet.

Automatic tests are great but hadn’t it been better if one didn’t have to test at all?

I will get back on the subject.

>The right solution is often the right

October 17th, 2007

>This message will be repeated in english.

Den “rätta” lösningen, d.v.s. den som en habil programmerare helst vill göra, är ofta den riktiga. D.v.s. den som är snabbast, billigast och/eller bäst.

Jag har inga siffror eller ens halvobjektiva mätningar eller exempel utan bara en känsla efter att ha drömt mig tillbaka i projekt. Felaktigt användande av “Rätt” lösning skapar måttlig extra kostnad medan felaktig lösning kan bli hur dyrt som helst.
Förutom att bli billigare, rent kontomässigt, gör det programmeraren gladare med. Han får möjlighet att skriva trevligare kod och kanske t.o.m. testa en teori. Detta ger bättre kod.

The “right” solution, the one the programmer prefers, is often the correct one. The one that is cheapest, fastest and/or best.

I don’t have any numbers or even halv objective statistics to support my case but only a feeling after having thought back att earlier projects. Implementing too many “right” solutions adds marginally to the cost while using the wrong solution has no upper limit.
Besides being cheaper in the long run the programmer is also happier with being able to create nicer code and even test a new theory. This gives better code.

>What priority levels to choose

July 17th, 2007

>When choosing how to number priorities I usually use 3 levels:
1) Critical. These are show stoppers. Without these fixed, the whole system is a waste of money.
2) Workaround exists. The customer have to call you (the developer), they might have to buy new hardware or send a backup copy by airmail deluxe. But a workaround still exists.
3) Cosmetic. This is anything that the users can figure out the solution for by themselves.

These 3 levels are not enough so they have 3 priorities in turn. 1, 2 and 3.

All in all 9 levels.

It is so simple it seems to work.

>Even n-n relation tables should have a simple PK

June 18th, 2007

>Continuing with the above/earlier I say that even the table to create a many-to-many relationship should have a simple primary key.
Table User_Role
– field UserRoleID PK
– field UserID FK
– field RoleID FK

As long as harddisk space is cheap and a simple PK does not create a performance impact there should be no reason to not have a simple primary key.

>Top down or bottom up

June 17th, 2007

>The discussion whether to design software bottom up och top down died with intellisense/typeahead/whateveryoucallit; it was so much easier building bottom up. Then refactoring tools entered and suddenly made it easy to program top down again.
Personally I believe the two methods should be mixed. Not like “these methods or modules we design top down and these bottom up” but more like “these methods we design no matter the way”.

Like this:
Here is a method I’d like to have. Here is the call. There is the method signature automagically created. Then some implementing code. And further calls to yet non-existing methods. Which are automagically created. Until we get all the way to the bottom. Where we adjust a couple of parameters. And refactor this up again. And adjust. And refactor. Until we are back where we started with code that is readable both if you track it from the top or the bottom.
Or the other way around if you prefer.

As long as the code gets readable. And updatable.