Getting back to Domain Driven Design

I recently started reading Domain Driven Design by Eric Evans and am gaining some insights into many of the DDD design practices I have unknowingly been using over the past 5 years.

It is interesting to see how over time aspects of my companies domain design has been muddled and broken down over time due to the miscommunication of the UBIQUITOUS LANGUAGE we developed in the initial design of the system.

This quote from the FACTORY/REPOSITORY chapters was quite pungent and applicable to our current environment when I read it:

"A client needs a practical means of acquiring reference to pre-existing domain objects. If the infrastructure makes it easy to do so, the developers of the client may add more traversable associations, muddling the model. On the other hand, they may use queries to pull the exact data they need from the database, or to pull a few specific objects rather than navigating the AGGREGATE roots. Domain VALUE OBJECTS become mere data containers. The sheer technical complexity of applying most database access infrastructure quickly swaps the client code, which leads developers to dumb down the domain layer, which makes the model irrelevant."

Also, in discussing the corrosion of the domain model he mentions how making it easy to convert data into objects using mapping layer can lead developers astray. Developers don't think of objects but just think of data containers. Is this the debate between DataSets and Business Objects a wolf in sheep's clothing?

"As a client code uses the database directly, developers tempted to bypass model features such as the AGGREGATES, or even object encapsulation, instead directly taking and manipulating the data they need. More and more domain rules become embedded in query code or simply lost."

I've been heads down in design and coding for so long in an attempt to establish the financial stability. I have been ineffective in the capacity as a System Architect in this regard.

My situation is rather humorous because the majority of Architects tend to spend too much time on Architecture related tasks where as I've been spending the majority of the last 5 years on design, coding, and support.

Also, people will fall back on the argument that any added abstraction is going to impact performance. Pooh to that! Depends on what you are building. If you are building a typical business app, design it correctly for God sake! Unit test it for performance and adjust as required. A good design is agile to change with TDD.

I look forward to reading more of DDD. It's stimulating new ideas and re-enforcing ones I already knew to be correct.

Esoteric and entertaining programming languages

If you ever have some times to waste I encourage you to check out the following programming languages. They are not really of any use but are a cool mental exercise.

Whitespace
BrainFu*k (or BF)

Whitespace is interesting because you embed secret messages through code within white space of your web pages.

Sure, go ahead and print out your white space program and destroy the source file. No one is ever going to figure it out now.

Apparently I had some time to waste this weekend.