Sunday, February 24, 2013

Minor observations on the ADF standards document

My original title to this post was: "Entity/Entities, Key abstractions and nouns". 

Just noticed this very useful document on "ADF naming and project layout guidelines" published recently. It represents a valuable and exhaustive resource that many projects and programmers (including myself) benefit from. 

I'm a fan of the 'convention over configuration' approach so prefer to leverage the framework/IDE features and default settings to the maximum (while attempting to keep myself aware of when and what to change)

On a few minor points, I have a slightly different preference [I don't suggest massive deviation from what the wizard creates - but these can add value in making names more meaningful and closer to how they model a business]:

1. Singular entity names

I prefer entity names to be singular**: Customer, Sale, Department, Employee, Location
So, for a table called SALES default entity name generated by the wizard would be Sales - my preference would be to change it to "Sale" (Actually my preference would be for the wizard to remove the plural spelling as far as possible...)
**My reasoning: A table as a whole represents all sales. But a row in a table represents a single 'sale'. 
Similarly, an instance of an entity represents a Sale just like an instance of the Customer entity represents one customer and not all the customers. 

In the (currently) more uncommon forward engineered scenario, the domain model would get designed first (crash course follows at the end)

(Ref: [ADFng1-04004] )


2. Marking cardinality

Another worthwhile standard I enforce is marking of the association cardinality clearly: (one to many, one to one, one to zero or many, many to one, many to zero or one). 

What a one to many cardinality between Department and Employee entities represents is this: For one instance of Department, there can exist multiple associated Employee instances


3. Cardinality in association names

As a consequence of 2, a preferred association name might be AccountCustomers or DepartmentEmployees  (both one to many), DepartmentLocation (could either be 'one to one' or 'one to zero or one')
This sort of encodes the cardinality of the association within the name (one to many in both the examples above). 
The same goes for one to one and many to one associations but I can't think of many examples now. 
This just serves to make it clear to the client (such as the UI) to expect a collection type (such as RowIterator) and not a single instance type (Row)

-------------------------------------------------------Crash course  for identifying entities - -------------------------------------------------------

One of the things I have always tried to stress is that while one can 'reverse engineer' entities and associations  from a relational database, these components fundamentally represent the business domain model.  

We start by reading an over-simplified requirement statement such as this:
A customer walks in to a bank branch, goes to the teller* and requests a new account. The teller logs in to the new system and enters the customer's details... and so on... 
(*Tech note: Teller = Employee? Role?)

The highlighted nouns are a fairly exhaustive list of my initial entity model for such a problem statement. 
Side note: And verbs usually evolve into usecases (and TaskFlows in the ADF world)

Nothing original in this but this is surprisingly identical to probably my first OOAD course in college!

No comments: