Enterprise Integration Zone is brought to you in partnership with:

Mitch Pronschinske is the Lead Research Analyst at DZone. Researching and compiling content for DZone's research guides is his primary job. He likes to make his own ringtones, watches cartoons/anime, enjoys card and board games, and plays the accordion. Mitch is a DZone Zone Leader and has posted 2577 posts at DZone. You can read more from them at their website. View Full User Profile

Hard Coding: A Design Approach

  • submit to reddit

Hard Coding: A Design Approach from Øredev Conference on Vimeo.

In this session, we will discuss the Great Simplification Architecture, instead of creating abstract towers of babel, we will see how we can create agile, maintainable and easy to work with architectures and systems that allow you to just go in and start working, rather than spend a lot of time an effort hammering everything in sight, looking for the nail that the architecture diagram's page 239 says must be there.

We will discuss layers reduction, useful testing strategies as well as cover some of the horrors that hide beneath the guise of "patterns", such as the repository and service monsters.


Mark Unknown replied on Fri, 2013/04/26 - 2:41pm

Don't waste you time on this video. I tried to watch it.  I have to agree that a lot of examples are bad. I don't agree why they are bad on how to solve them.

Here is the only good message - Use patterns appropriately.  

He is very smart and has created a good product. That does not make him knowledgeable on good architecture. 

Jose Fernandez replied on Mon, 2013/06/10 - 12:36am

The presentation style is very off-putting. He essentially says engineers are stupid if they don't follow his architecture style.

He suggests to use 8 abstractions at the most. This number is pulled out of thin air and does not consider the type or scale of application.

I agree that you shouldn't make too many abstractions, but if you can't easily navigate through application/service/repository layers, you should find a new line of work.

He says don't buy into the pattern hype, yet models everything after the Command pattern. So he is selective about why hype he buys into apparently.

There is some food for thought here and I will have to think about it a bit more. His approach makes me think of CQRS, which I like. He makes good points about unit test fragility and that most code designed for reuse is rarely reused. I might be more receptive to his approach if it wasn't delivered so abrasively.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.