Design is back. Long live design

It is very encouraging to read from the experiences of agile practitioners that they think up-front design (Architecture and framework) is too important to be left implicit in any methodology. I always believed in up-front design and evolutionary design facilitated by effective refactoring and automated testing, being core parts of any methodology. There are complimentary to each other, rather than forcing a programmer to use one over another. You dismiss one; you have a very lousy software at hand.

Martin Fowler also advocates nicely in making use of best of both worlds. It makes more sense now.
http://www.martinfowler.com/articles/designDead.html


http://codebetter.com/blogs/sam.gentile/archive/2006/09/06/Being-an-Agile-Architect.aspx

Being an Agile Architect
We found that a year down the road that there was still a lot missing. Too many "infrastructure" or "framework" things were blowing by in this delirious rush to crunch out 100% business functionality every week no matter what. Someone with Architecture experience needs to perform explicitly the role of Agile Architect and restore these capabilities to a team

http://codebetter.com/blogs/scott.bellware/archive/2006/09/19/149368.aspx

Sam's post on agile architecture has led to the death of my last vestiges of my denial in regards to a need for some formal recognition of software design on an agile team.

The absence of explicit software design activities on our team has lead to some degradation of software design that is leading the code down the slippery slope to opaqueness and to the initial indications of software entropy. We're trying to add a bit more formality to software design and software design guidance into our process. Recognizing a software designer's role on the team tasked with up-front design and continuous software design quality assurance is part of this effort.

Footnote:
It pays to be a coward Extreme Programmer

Re-read Head First Design Pattern-- my rating -- 5/5

Readability : 5/5
Information about Subject : 5/5

Couple of years back when I was exposed to Design Patterns, I went on buying spree for every computer book with design pattern somewhere in title. In that buying spree, I bought this book as soon as it hit the market. Now I am glad to see that this book is on every Architect’s book shelf. If GOF’s Design Pattern book was a Bible which only high priest(C++ Guys) could read and understand, this book spread the word of Design God to ordinary mortals(vb) and connected the ordinary programmers to OOP.
After reading these books, ordinary mortals could come up with a good or not so good OOP solution but never had they gone back to procedure programming.


After reading first few chapters, I think that Strategy Pattern can very useful.

If you could never understand Command Pattern, try this book.

Why do I perfer Custom Collection over Dataset?

I don't like dataset as a mechanism to transfer data between two layers for following reasons

1. Not a true OOP concept
I seriously follow Rockford Lhotka's writing and agree with him on this.

2. Bad Performance.
I did some benchmarking tests on Custom Collections vs. Dataset as being transport mechanism in Web Services Scenario in Net 1.0. Custom collections performed four times better than Dataset. I am sure in remoting scenario , difference would be more dramatic. I am going to perform very soon some benchmarks tests on .Net 2.0

More Details


3. More Code
One ends up writing more code in packaging and unpackaging data in dataset.Remoting and WebServices infrastructure takes care lot of Serialization and Deserialization issue. Before Generics, by getting rid of dataset, I was able to get rid of 1000s line of code and get more performance.
Recently I did some benchmark tests on generics from my office computer (Which has less memory) and got more encouraging results. I will post them very soon on my blog

4. Not SOA friendly
If datasets are exposed through WebSerivecs, only .net Clients can use these Web-Services.

Chirdeep Shetty has very a nice post about problems that he faced to convert C# WebServices to Java WebServices because of dataset and workaround.



Having said that I may use Dataset/DataTable in following situations
1. When I have a situation where columns of a custom collection are variable. DataTable/Dataset IMO offers more clean solution.
2. Disconnected rich client architecture

Is 3 Layered Architecture = MVC

Very nice discussion is going on this thread.

http://forums.asp.net/thread/1379168.aspx
At first after reading the post, I also got confused by striking similarities between two patterns thought one is design pattern other one is application pattern.
Survic has written a nice post on confusion regarding MVC.

This is one of best articulated posts that I have come across on this topic.


If you don’t understand confusion about MVC then read

First there are two documented versions of MVC
http://www.javaworld.com/javaworld/jw-12-1999/jw-12-ssj-jspmvc.html

Here is sample of discussion on MVC and ASP.Net in which I took part
http://forums.asp.net/2/1249964/ShowThread.aspx


If you thought that this is enough then there is a MVP pattern.

Example of
http://codebetter.com/blogs/jeremy.miller/archive/2006/07/11/147305.aspx

After that Martin Fowler splits MVP into two parts to clear confusion (But now I am more confused)
http://geekswithblogs.net/billy/archive/2006/07/20/85815.aspx
http://martinfowler.com/eaaDev/PassiveScreen.html
http://martinfowler.com/eaaDev/SupervisingPresenter.html



I always use MVC as GUI or WEB based design pattern.
MVC is a design pattern for Interactive Interfaces.(LudovicoVan corrected me)
MVC in web context is more geared towards streaming HTML to different devices that understand HTML while 3 layer architecture is independent of any technology.
http://www.martinfowler.com/eaaCatalog/
http://www.martinfowler.com/eaaCatalog/modelViewController.html

One comment was that we should implement MVC in every layer of application.
I think that I know what the poster is implying.
Generally I believe in understanding the intent of pattern and implementing it my way that suits my project. But at the same time, we have to maintain some essence of design pattern for clear communication. While I understand what the poster is implying, I think that are specific patterns (factory,fascade,process layer,Aggregation etc) to describe the patterns applicable to good enterprise distributed computing needs.

Note: I am going to revisit this post

Showing Chinese or Japanese Characters in Charting / Graphing Tools

I was evaluating third party Charting Controls for our application. Somehow I was not able to show Chinese/Japanese characters properly on my machine. I was wondering whether it is problem with third party tools or my code. Finally after working with vendors, I found out problem was with my machine.
I am documenting this in my blog just in cause someone needs this info.

It is possible to show Chinese/Japanese characters in most of the charting tools. The only thing you need to do is have the Asian language pack installed. To do this; go to control panel -> Regional and Language Options then click on the language tab. From here, check the “install files for East Asian languages”. This will allow you to view Chinese on your machine. Once this is installed, all you need to do paste the text directly into the fields in the chart and it will show up properly.

Domain Driven Design based on Entity Model vs E/R Model

Continued from
http://vikasnetdev.blogspot.com/2006/07/domain-driven-design-vs-data-driven.html

Survic said
“I agree with you about the size of projects; but deep in my heart, I also believe that all larger business projects can be split into smaller projects, so, I do not believe “TDD with mocks and DDD without data” is good for anything -- I will keep an open mind though”


Hi Survic,
Thanks for pointing to Scott W. Ambler.’s book ‘The Object Primer’. It helped me to write this post. That is what I wanted to articulate in first place
First thing nobody is underestimating the importance of Data in Domain Driven Design. But there are following problems or realities in Enterprise Data Design (Scott calls Legacy Database design but DBAs continue to employ for consistency purpose)

1. A single data field is use for several purposes.
2. The purpose of a data field is determined by the value of one or more other columns.
3. Inconsistent values are stored in a single data field.
4. There is inconsistent/incorrect data formatting within a column
5. Some data values are missing with in a data field
6. One or more data fields that require do not exist.
7. Additional data fields that your application will need to support if it uses the legacy data exist
8. Multiple source exist for the same data and it is not clear which one to use
9. Important entities, attributes and relationship are hidden and floating in text fields
10. Data values can stray from their field descriptions and business rules.
11. Various key strategies are used to identify the same type of entity
12. You require a relationship between data records that is not supported by legacy data.
13. One attribute is stored in several fields.
14. Special characters within a data field are inconsistently used.
15. Different data types are used for similar columns.
16. The legacy data do not contain sufficient detail.
17. The legacy data contain too much data.
18. The legacy data are read-only, yet you require update access.
19. The timeliness of data varies from what you require
20. The default value used by a legacy application does not reflect the default value required by your system.
21. Different representations of the data exist.
22. The naming conventions used are difficult to understand

As per my experience with DBAs in past,Some decisions may be right in their own way. They are more concerned about efficient storage of data; need to be consistent with existing databases (what Scott calls legacy) and future extensibility at data storage level.

Some of above factors limit the database design diagram to be used as effective communication tool with all stakeholders. We need a abstraction above database which hide these complexities and communicate more clearly Problem Domain/System Blueprints to users.

This is where come entity classes’ diagrams (Since we both agree on importance of process classes diagrams, activity diagrams, Sequence diagrams etc.) which can hide all above mentioned storage details from system users. It will help the programmer to nail down the requirement and prepare the blueprints with out waiting for database design to be over. Once requirements are completely nailed, data storage/retrieval is more implementation details.

This debate is similar to XML Hell debate. Nobody is arguing against the importance of XML but we need an abstraction/Graphical tools to hide its rawness as discussed in the following mail
http://vikasnetdev.blogspot.com/2006/06/xml-hell.html

Reference:
The Object Primer – By Scott W. Ambler

Domain Driven Design-- My Rating 3-4/5 -- Currently Reading

This book will influence one to employ Domain Driven Methodology even in a pure Waterfall or fixed bid project. You will not like to be caught with out a Domain blueprint in Design phase after reading first five chapters book and will know the importance of Ubiquitous Language.

My criticism of book is that if you are well-verse in design patterns,Analysis patterns ,OOP concepts that book discusses, you may find little value in chapter 6 - 13. Authors should have shortened them into two or three chapters.

If you are new to Application and Design Patterns,Analysis Patterns and OOP , you will find this book more useful.
I am glad that I read it and it is over. (read 60%). I have to still read Chapter 14-17. May be some other time.

SOA Friendly Architecture version of Jeffrey Palermo's Architecture -- Part 2 -- Architecture

As always, Survic raised excellent Questions and gave excellent suggestions about my previous post. Survic comments/questions are in bold.


“Business Object Manager” (I guess it is the “Façade Object” -- it is very popular to use "XX_Manager" and "XX_Facade" interchangeably)Business Object Manager is a Mediator between Business/Entity Object and Data Object Layer. It provide an opportunity to aggregate the business objects on Database server and send aggregate object at once to Application Server. This particular element is missing in Jeffery’s Architecture (I could be wrong) or in Pet Shop Architecture (I am very sure because I am burnt by it).
It also enables Business Object Layer and Business Transfer Object to one layer instead of being multiple layers as shown in the code.


Process Object” (I guess it is the “Workflow Object”)

Yes, Survic is right.
All the Workflow logic, additional processing, co-ordination and control logic will go there.


Repository Object” (I’m pretty sure it is the “Façade Object”).
In my case, it is responsibility of Gateway/Factory Layer. I may take out of Architecture diagram.

Application architectures” and “service architectures” are critically different?No. There are subtle but major Design differences.

SOA = Good Distributed Programming Practices + Message Version Control + More Loose Coupling
In Distributed Architecture/Client Server Architecture, generally you may have control over client applications. In my internal application architecture, I can make changes to Business Object layer and regenerate the proxy object and recompile the Gateway/Factory Layer and make changes to UI. So there is little tight coupling between server side component and consumer application. Basically I am sharing code with Consumer application. Performance is big concern. It is more RPC style of communication
Distributed computing is also more end-to-end integration. Component A connects to Component B and component B connects to Component C

In Service Oriented Architecture, you don't have control over client applications or other consumer Services. in general. You have to be more subtle over version control. You share contract and chances are that your application may support multiple contracts.In that scenario, I design the Incoming message as XML string and share XML Schema with client. That way Interface of Service always remain same (no need to regenrate WSDL )but you message structure may change. It is more Document Style of communiction.
SOA is more like workflow. Component A may connect to Componet B or may be Component C.
Here is nice article by Rockford Lhotka

However I think that if you have good Middle Layer, adding a true service layer should be a small issue.

Microsoft Architectue
Do they have some implementation code? My interpretation is same like you. It is decent architecture if we both are right. Last time , I used pet shot .net architecture, it left a very bad taste in mouth. :)

SOA Friendly Architecture version of Jeffrey Palermo's Architecture -- Architecture

Please Note:

I am retiring this implmentation with a new implmentation using WCF, though the
Architecture remains same.
http://vikasnetdev.blogspot.com/2006/12/my-default-soa-architecture-using-wcf.html

This post is inspired by Jeffrey Palermo's post on Application's Architecture


Though it is quite superior as compared to .Net Petshop Architecture, I really doubt that this architecture will scale for distributed computed scenario like petshop architecture does not. Jeffrey may have answer for this. So I came up this SOA friendly architecture which is being used at one of my client's place. I am also going include some feature from Jeffrey'a Architecture like Presentation layer (MVP vs MVC) in my architecture

Note: The author of this blog does not believe that you should use WebSevice in standalone application when none required. But we live in a world where we don't make rules. If you database is protected by another firewall, you may find this architecture handy. It is more important to have logically separation in architecture that will scale well if application is deployed in a distributed manner.


Here is SOA friendly Architecture


Here is deployment view


Major Components

1. UI Components/Views:
Provide User Interface

Controllers
Get the Business Objects from Gateway and provides to UI

Gateway/Factory
It is factory layer that provides the business object. It knows how to create or get the object across the network boundaries. First looks in repository if none, gets the object across the wire.Our example is going to exploit the capabilities of Web Service. It will convert the proxy object into real domain object using Mapper utility.

References:
http://www.martinfowler.com/eaaCatalog/gateway.html
http://www.martinfowler.com/eaaCatalog/repository.html
http://www.martinfowler.com/eaaCatalog/dataTransferObject.html


Business Object Manager
It populates the business object using data object. This is where one can aggregate the business objects before transferred across the network.


Business Object/Entity Object
Contains the Attributes and operations related to domain entity

Process Object/Workflow Object
Business objects collaborate together to perform some useful operations to users.


Data Object
Data Objects retrieve the data from Database. Will contain all the CRUD operations.

Here is Code.

Gateway

namespace Gateway
{
public class Contact
{
static Contact()
{
//
}

private static List contactListCache = null;
private static Object syncRoot = new Object();

public static void ClearCache()
{
lock (syncRoot)
{
contactListCache = null;
}
}

public List GetContact()
{
return ContactList;
}


public List ContactList
{
get
{
if (contactListCache == null)
{

lock (syncRoot)
{
contactListCache = new List();
ContactWS.ContactService ws = new ContactWS.ContactService();
ContactWS.Contact[] proxyContactList = ws.GetContacts();
contactListCache = (List)Mapper.MapProperties_Fields((System.Collections.IList)proxyContactList, typeof(List), typeof(BusinessObject.Contact));
}

}
return (contactListCache);
}
}

}
}



namespace Gateway
{
public abstract class Mapper
{

public static object MapProperties_Fields(object SourceObj, Type DestinationType)
{
if (SourceObj == null)
{
return null;
}
Type sourceType = SourceObj.GetType();
object destinationObj = Activator.CreateInstance(DestinationType);

foreach (PropertyInfo sourceProperty in sourceType.GetProperties())
{
MemberInfo destinationMember = DestinationType.GetMember(sourceProperty.Name)[0];

if (destinationMember.MemberType == MemberTypes.Property)
{
PropertyInfo destinationProperty = ((PropertyInfo)(destinationMember));
if ((destinationProperty.CanWrite == true))
{
if (destinationProperty.PropertyType.Equals(sourceProperty.PropertyType))
{
destinationProperty.SetValue(destinationObj, sourceProperty.GetValue(SourceObj, null), null);
}

}
}
}
return destinationObj;
}



public static IList MapProperties_Fields(IList SourceList, Type DestinationListType, Type DestinationElementType)
{
if (SourceList == null)
{
return null;
}
IList destinationList = ((IList)(Activator.CreateInstance(DestinationListType)));
foreach (object sourceObj in SourceList)
{
destinationList.Add(MapProperties_Fields(sourceObj, DestinationElementType));
}
return destinationList;
}



}
}




WebService
namespace BusinessObjectWebservice
{
///

/// Summary description for Service1
///

[WebService(Namespace = "http://tempuri.org/")]
[WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]
[ToolboxItem(false)]
public class Service1 : System.Web.Services.WebService
{

[WebMethod]
public List GetContacts()
{
BusinessObjectManager.Contact contactManager = new BusinessObjectManager.Contact();
return(contactManager.GetContacts());
}
}
}



Business Object Manager
namespace BusinessObjectManager
{
public class Contact
{
public List GetContacts()
{
DataTable dataTable;
List list = new List();

dataTable = DataObject.Contact.GetContact();
try
{
foreach (DataRow dataRow in dataTable.Rows)
{
BusinessObject.Contact contact = new BusinessObject.Contact(dataRow[0].ToString(), dataRow[1].ToString(), dataRow[2].ToString(), Int32.Parse(dataRow[3].ToString()));
list.Add(contact);
}
}
catch (Exception ex)
{
throw ex;
}
finally
{
dataTable = null;
}

return(list);
}

}
}


Business Object

namespace BusinessObject
{
public class Contact
{

private String _userName;
private String _name;
private String _phoneNumber;
private int _age;

public Contact()
{
}

public Contact(string userName, string name,String phoneNumber, int age)
{
_userName = userName;
_name = name;
_phoneNumber = phoneNumber;
_age = age;
}


public String UserName
{
get
{
return _userName;
}
set
{
_userName = value;
}
}

public String Name
{
get
{
return _name;
}
set
{
_name = value;
}
}

public String PhoneNumber
{
get
{
return _phoneNumber;
}
set
{
_phoneNumber = value;
}
}


public int Age
{
get
{
return _age;
}
set
{
_age = value;
}
}

}
}


Data Object
namespace DataObject
{
public class Contact
{
private const String ContactTableName = "Contact";

private class Fields
{
public const string UserName = "ContactUser_Name";
public const string Name = "Contact_Name";
public const string PhoneNumber = "Contact_Phone_Number";
public const string Age = "Contact_Age";
}


public static DataTable GetContact()
{
System.Text.StringBuilder sql = new System.Text.StringBuilder();
System.Data.DataTable dataTable;

//Build the SQL

AppendBaseSelectColumns(sql);

sql.Append(" FROM");
sql.Append( " " + ContactTableName);

try
{
dataTable = GetDataTable(sql.ToString());
}
catch (Exception ex)
{
//Log the error
throw ex;
}


return(dataTable);


}

private static String AppendBaseSelectColumns(System.Text.StringBuilder sql)
{

sql.Append("SELECT");
sql.Append(" " + Fields.UserName + ",");
sql.Append(" " + Fields.Name + ",");
sql.Append(" " + Fields.PhoneNumber + ",");
sql.Append(" " + Fields.Age );
return sql.ToString();

}

private static DataTable GetDataTable(string sql)
{
//Real life one will connect to Database and return the
DataTable dataTable = new DataTable();
dataTable.Columns.Add(new DataColumn("Contact_User_Name", typeof(String)));
dataTable.Columns.Add(new DataColumn("Contact_Name", typeof(String)));
dataTable.Columns.Add(new DataColumn("Contact_Phone_Number", typeof(String)));
dataTable.Columns.Add(new DataColumn("Contact_Age", typeof(System.Int32)));
dataTable.Rows.Add(new Object[]{ "VK", "Vikas","222-222-2222",int.MaxValue});
dataTable.Rows.Add(new Object[] { "SV", "Survic", "222-222-9999", int.MaxValue });
return dataTable;

}

}
}


Presenter/Controller
namespace Presenter
{
public class ContactPresenter
{
public ContactPresenter(View.IContactView view)
{
_view = view;
_view.LookUp += new EventHandler(_view_LookUp);
_view.Persist += new EventHandler(_view_Persist);
}

private View.IContactView _view;
private BusinessObject.Contact _currentContact;


public View.IContactView View
{
get { return _view; }
}
public BusinessObject.Contact CurrentContact
{
get { return _currentContact; }
}


public void SaveContact()
{
if (_currentContact != null)
{
_currentContact.Name = _view.ContactName;
_currentContact.PhoneNumber = _view.ContactPhoneNumber;
_currentContact.Age = _view.ContactAge;
}
}

public void LookUpContactByUserName(string userName)
{
Gateway.Contact contactGateway = new Gateway.Contact();
List contactList = contactGateway.GetContact();

foreach (BusinessObject.Contact contact in contactList)
{
if (contact.UserName.ToUpper().Trim().Equals(userName.ToUpper().Trim()))
{
_currentContact = contact;
break;
}
}

_view.ContactUserName = _currentContact.UserName;
_view.ContactName = _currentContact.Name;
_view.ContactPhoneNumber = _currentContact.PhoneNumber;
_view.ContactAge = _currentContact.Age;
}

private void _view_LookUp(object sender, EventArgs e)
{
this.LookUpContactByUserName(_view.UserNameToLookUp);
}

private void _view_Persist(object sender, EventArgs e)
{
this.SaveContact();
}
}
}

Converting NUnit Tests to MSTest

I have been deliberating for some time whether to stick with NUnit or go for MSTest.
http://vikasnetdev.blogspot.com/2006/07/eight-point-checks-for-servicing.html

Advantages of MSTest over NUnit
1. Excellent IDE Integration
2. Code Generation
3. New Attributes
4. Enhancements to the Assert class
5. Built-in Support for testing non-public memembers.

After hearing from the colleague that debugging NUnit tests is not working great with Visual Studio 2005, I decided to plunge into MSTest. First step is figure out how move previous NUnit tests to MSTest. Here are steps

Step 1: Start with James NewKirk’s blog post

Step 2: Download the NUnit Converter V1.0 RC1 from workspace


Step 3: Install the Guidance Automation Extensions & Toolkits from link


Step 4:Double-click the file: “NUnit Converter.msi” to install the converter. One caveat: It has not been tested in any other directory than the default directory. This of course does not mean it will not work in a different directory it just means that it might not. Also the rest of the instructions assume you have put it in the default directory. You can think of this as a strong hint to leave it in the default directory.

Step 5: Start Visual Studio 2005 Team System.
Step 6: Open a solution file that has existing NUnit test code.
On the Tools menu, click Guidance Package Manager. A dialog box should open, see below. You should check to make sure that the “Convert NUnit Test Code” Recipe is present. Then click Close.





Step 7: You have completed the installation.


Step 8: Back-up the files and their associated project and solution files. This step is critically important. There is no automated restore of your files back to a previous state.

Step 9:Start Visual Studio 2005 Team System.
On the File menu, navigate to Open, click Project/Solution. Navigate to the directory where the Project/Solution is contained and then select the file you wish to open.
On the File menu, navigate to New, click Project. Select the appropriate (C# or VB.NET) test project and place it in the directory of your choosing. See “Tests must be in a Test Project” below.
Copy each file that contains NUnit test code that you want to be converted into the test project.
Add any required references (including a reference to NUnit) and compile the test project. Once the code compiles, run the tests in NUnit to ensure that you are starting with a working test harness. This step is optional but I like to do it because if the conversion process introduces problems, I know that I started with a working baseline.
Step 10: Now onto the conversion process. Right-Click the test project that you created in previous step in the Solution Explorer. Click the Convert NUnit Test Code. As each file is being converted it will be opened in Visual Studio. When the conversion is complete, the conversion results will be displayed.
Once you have completed the conversion process you should disable the guidance package. The reason is that every time you right-click in the Solution View the guidance package looks for NUnit test code. If there isn’t any to find it just wastes time. On the Tools menu, click Guidance Package Manager. A dialog box should open. Click Enable/Disable Packages. You should uncheck “NUnit Test Code Conversion”. Then click OK.

Domain Driven Design vs Data Driven Design -- Domain Driven Design

Subscribe to my youtube channel "Software Architecture Matters!!!"

Survic has very nicely argued that database storage and retrieval is 80% ( I would say 70%) portion of application. Mocks ups, Screen Design and database will help to achieve completion of 80 percent of system.
I agree 100% with you that if you have a short term project with no future releases, data driven design is more efficient. My argument is Mock ups, Domain Design and Database Design (in that order. Domain Design and Database Design could be parallel activities in some organizations) will not only help achieve 100% but is also cost effective for project with multiple releases.

Rest of 20% is too important to left open to risks of communication failure
Nothing more make sense to Business User more than Mock ups, Screen Shots or prototype. You win the 80 percent battle if you have these ready with Database design. But left 20% is too important to left open to communication failure.
Rest 20% is like collaboration mechanism that integrates all the parts of plane and help you fly the plane and reach the destination. Fact that you all parts are complete and you get the mechanism wrong would result in system failure.
Now back to real world, we get the 20% right in the sense; they deliver the business value but are written in procedural style hard-coded in the front end. Thus it results in weak business layer. Experience developers will notice patterns and in next iteration, we will refactor the 20%. That brings me to next point

Domain Driven Design requires more time.
Domain Driven Design is a more reverse thought process. As you put it, first figure out the data needs and perform the domain design. Problem is thinking in terms of data needs will create communication failure. There is good case study example in Domain Driven Design ( I have read only 10% of book). Here is excerpt from book

Users:

So when we change the customs clearance point, we need to redo the whole routing plan.

Developer:

Right. We'll delete all the rows in the shipment table with that cargo id and we will pass the origin, destination, and the new customs clearance point into the Routing Service, and it will re-populate the table. We'll have to have a Boolean in the Cargo so we'll know there is data in the shipment table

Users:

Delete the rows. OK, whatever

Reference: Domain Driven Design -- by Eric Evans.

There is no concept of any domain analysis in most project that I have done. You have screen shots, process flow or activity diagrams and database ready, let us move to development. Class diagrams more reflect the database rather than domain.
So you are going to be get all entity classes right and no or light controller or process classes. Experienced developers will notice all common patterns but there is not time to apply patterns as there is a deadline to meet. In next release, experienced developers will sneak in design patterns, controllers and process classes. If something breaks down in application that was scoped not to be affected during impact analysis in release, you will to answer the Project Manager.

Domain Driven Design is good and no Domain Driven Design has costs
In my analysis, Domain Driven analysis will help you get 10 – 15% out of 20% right in first release. Returns on investment are higher in long term and less risk. Performing Domain Analysis first before data requirement will help the communication and no Domain Analysis has costs.


People understand Mock Screens More
In theory, perhaps, you could present a user with any view of a system, regardless of what lies beneath. But, in practice, a mismatch causes confusion at best—bugs at worst. Consider a simple example of how users are misled by superimposed model of bookmarks for Web sites in current releases of Microsoft Internet Explorer.

Of course, an unadorned view of the domain model would definitely not be convient for the user in most cases. But trying to create in the UI an illusion of a model other than the domain model will cause confusion unless the illusion is perfect.


People don’t understand Objects
MODEL_DRIVEN DESIGN calls for an implementation technology in tune with the particular modeling paradigm bend applied. At present, the dominant paradigm is object-oriented design and most complex projects these days set out to use objects, some are circumstantial, and others derive from the advantages that come from wide usage itself.

Many of reasons teams choose the object paradigm are not technological, or even intrinsic to objects. But right out of the gate, object modeling strike a nice balance of simplicity and sophistication.

The fundamentals of object oriented design seem to come naturally to most people. Although some developers miss the subtleties of modeling, even non technologists can follow a diagram of an object model.
Yet, simple as the concept of object modeling is, it has been rich enough to capture important domain knowledge. And it has been supported from the outset by development tools that allowed a model to be expressed in software.

Objects are already understood by a community of thousands of developers, project managers, and all other specialists involved in project work.


When a design is based on a model that reflects the basic concerns of users and domain experts, the bones of the design can be revealed to the user to a greater extent than with other design approaches. Revealing the model gives user more access ot the potential of the software and yields consistent, predictable behavior

Reference: Domain Driven Design – by Eric Evans

Data Driven Design to Domain Driven Design—Facilitator Fit -- Fit

After exploring Fit, I am convinced that Domain Driven Design is way to go.

Data Driven Design creates a communication gap between business user and programmer. Data driven design forces programmer to think more about persistence and data storage needs rather than problem domain. Programmer ends up throwing lot of technical mumbo jumbos at business user. This leads to communication failure.
When business user and programmer arrive at Fit table, next step is to map Fit table to Software’s Business Layer to validate the Fit Table. Mapping will be smoother if Business Layer Class Model mirrors the problem domain. Close mirroring will encourage the programmer to speak in business user’s language and facilitates good communication.
I was employing data driven design with pragmatic use of Design Pattern. Now I am going to focus on Domain Driven Design and speak in Business Users language.
For a start, I am going to read Domain Driven Design by Eric Evans

Eight Point Checks for Servicing Software -- Servicing Software Part 3

I am updating my post part 2. I am replacing terms nunit with automated testing and nant with continuous integration build.

With the advent of Team System, I think that I am going to explore its automated unit testing and continuous integration capabilities. It was a hard decision since I really loved these open source frameworks. I think that they did a great service and have outlived its utility.

I am hoping that Team System has done a good job of integrating these frameworks with IDE.

Next couple of days I am going to Explore Team System capabilities