Wednesday, May 27, 2009
Domain Driven Design – Quickly
Lately I’ve been wanting to read Domain Driven Design book by Eric Evans but then I found Domain Driven Design Step by Step by InfoQ and just in the foreword it says that I must read DDDQuickly also by InfoQ before proceeding, so I downloaded it (PDF)and started reading a few chapters.
I have now stopped reading the book mainly because it got to the point where I thought I needed to see a concrete example of it’s implementation in C#/.NET which I couldn’t find and also because I have found another great read.
Below are some of the notes that I think are the key takeaways from the read so far, I’m sharing them here thinking they might be useful to someone with a disclaimer that they are my notes and I make no warranties for the accuracy, if you are serious about DDD than start reading the book.
Domain - knowledge of the the domain is important before building software, e.g. for banking. Bankers know better about the rules that anyone else.
Model - Is the internal representation of the domain, we must communicate this upfront to all the stakeholders in a software design, the domain experts, domain analysts and off course developers.
Ubiquitous Language - when domain experts and developers talk they often use some keywords use to describe the system, these keywords make up the domain that is used in UML diagram and Documents explaining those diagrams and ultimately in Classes and Variable names in the code.
Analysis model - a model created by domain experts while not taking into account the software used to code therefore make matter worst at software design time, where developers have to make few decisions on their own. The idea is to choose a model that can be appropriately represented in software.
The key is to involve developers at Domain Model design stage with Domain experts and analysts to let them get the first-hand knowledge of the domain rather than having to understand it with the help of diagrams and documents.
Entities - entities should be unique and defined with a ID, not everything should be Entity but it can be Value Object
Value Object - are unchangeable objects with no unique IDs and created using Constructor, their values cannot be and must not be changed, if new value is needed, simply create another Value object.
Labels: Architecture, Domain Driven Design
Thursday, May 14, 2009
VS 2010 Beta 1 and Functional UI Testing
I just watched a video over at Channel9 which explains how to leverage some of the UI Testing capabilities that are going to be introduced with VS 2010 beta 1 expected next week.
Visual Studio had testing capabilities for C# code for a long but now I’m glad to see for the first time an integrated UI testing built right into VS 2010 IDE. In particular I like the option to store the tests in the database and be able to run them automatically.
See it for yourself, there is also a Mix09 video here
Labels: .NET 4.0, UI Testing, VS 2010
