-
SOA and the domain model
-
Frans Bouma touches the architectural topic of object-message mapping (or what Martin Fowler calls Data Transfer Object).
Do we need an domain model when working in a SOA (a.k.a. the moving target of today) environment and hence a way to map SOA's message oriented nature onto the object oriented nature of the domain model? I think it's a matter of context, complexity, personal architectural liking and who was there first, namely the chicken(SOA) or the egg(domain model)?
Context:
- What's a service?
- How do you envision your services?
- Who will be the consumer of your services and to what end/purpose will they be consumed/used for?
Complexity:
- How complex will the logic behind your service to be?
- Exactly how coarse-grained are they (your services) going to be?
- Are you going to reuse the logic inside your service (e.g. in another service)?
- Are you going to reuse that logic in a non-SOA environment?
- Will a domain model allow you to better understand and maintain your logic?
- What's the added value of having a domain model behind your service?
Personal Architectural Liking:
- How did you develop services before the SOA hype?
- Is a service an orchestration of cooperating domain objects or an orchestration of other services and messages, to you?
-
Do Da Unit Testing Database
-
When working with temporal data stored in an RDBMS it can be tricky to do proper unit testing (actually it's nearly impossible). Essentially, to be able to re-run unit tests you need to be able to restore time and space like it was the previous run. A technique I found usefull was explicitly setting the system time before starting the actual test (PInvoking a Win32 API). After the test had run, I'd just sync up with the domain controller using net time. Ofcourse, it's never going to be 100% the same, but for most non-real-time systems this will do.
A common problem when doing unit testing is restoring a database(SQL2K) reliably to a known state. The good news is that it's quiet simple (and compared to database recreation via scripts, very fast)!
- Make sure your database has it's AUTO_CLOSE option set. Detach it and remember where that .mdf is located!
- The connection string used by your DAL or ObjRelMapper should look like: "Data Source=(local);Initial Catalog=MyDataBase;AttachDBFilename=D:\MyDataBase.mdf;Pooling=false;Integrated Security=true;"
- AttachDBFilename points to the detached database(a copy would even be better).
- Pooling=false ensures you will be able to detach the database later on (should we want to) and that you can re-run the unit tests without exiting the test environment.
- If you want to detach your database, use a connection string which connects to the master database and do an sp_detach_db of your test database. This will allow you to move the .mdf around.