You have a great point on the network effect in systems.

It is amazing to see how some small logical and architecture bits can stack up if you keep them in mind while working within the scope of subsystems (i.e. Automation Engine, Data Server, Web UI, Desktop UI).

Basically the components and their relations start turning into higher level meta-programming language that you can use to assemble sub-solutions dealing with business objects, processes and workflows.

But in order to get that synergy effect, a certain degree of logical flexibility and abstraction is needed in the right spots. Spots that do not gain enough from being flexible are better to be hardcoded.

I absolutely agree with you on the importance of the resources in any given project. Obviously, the time, money and available development pool are the constraints that affect any development process, architectural and logical decisions (they’d better or the project will be inefficient).

And frequently due to the resource pool limitations one has to “stay low” in the code and trade away some ease of change and extension for maintainability in order to deliver project successfully.

However, in xLim implementations I have the luxury of trying to get as much extensibility and abstraction as possible while keeping it logical, just to see how things work out together and what “silver bits” are the most rewarding.

So many of these techniques and technologies are mutually supporting and have so many great network effects that it can often be hard to see which angle someone might be coming at it from, and as such I can totally understand your comment.

My primary “angle” is that I need testable code, in this case specifically testable entities. I would also like to avoid the anemic domain model anti-pattern. To avoid it, I need entities that can make use of services. To make those entities testable, I need their service dependencies injected. It can be hard to do that, however, when instantiation of the entities is out of my control, eg. when an ORM instantiates and populates the entity objects.

For me, at least, it is this testability that is key. Abstraction is useful, but as you point out must always be treated solely as a means to a reasonable end. For me, abstraction is secondary to testability, though it often can be achieved in good support of testability.

Just a small point, but from a manager’s perspective I would question whether you are going down a slippery slope of continually trying to abstract away everything from everything. When does adding “just one more” layer of abstraction end? In a large organization with a diverse developer base, such an approach leads to less maintainable code given average developer skills, and that is less desirable than testability or re-usability. The journey to a “silver bullet” framework that is loosely coupled in all circumstances, too often ends up in a complex framework that only the author(s) can use.

I may not post right away, since the logic behind ORM+IoC repository needs some thought, but my next post in the weblog will be on the subject.

I usually try to stick to my words and if you notice any big statement of mine that feels fallible or simply wrong, feel free to tell me. I will really appreciate that.

Rinat

PS: The joke about the hours in day comes from the Google group on autofac where Nick wished to increase the default values on the weekends))
http://groups.google.com/group/autofac/msg/a7fa1e26dc4b1767