TL;DR
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.
>
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.
>
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.
>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.
>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.
>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.
>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.