Posts Tagged ‘theory’
Simple Made Easy
An outstanding presentation on what “easy” means and what “complex” means by Rich Hickley, the author of Clojure.
If you are somehow related to the software development it will be absolutely worth your time to watch it.
Anemic Domain Model
Today I stumbled across a conversation about the Anemic Domain Model.
It sounds like a some sort of terrible disease. Martin Fowler blasted it as an anti-pattern. Wikipedia page states 1 benefit to 7 liabilities.
Even people that humor it tend to say it is limited to only inexperienced teams and small projects:
Jimmy Bogard writes:
Times when you can’t do a full domain model can include situations where you don’t have access to a domain expert, your team isn’t experienced with OO, or time constraints limit the conversations and analysis needed to build a decent domain model. If the domain isn’t complex, or is largely data-in, data-out, then those are contexts where a full domain model likely isn’t needed as well.
Greg Yong writes:
Our domain is not extremely complex…. Our team is not highly functional in object oriented design and analysis. When I say this I mean that team members must be highly functional in order to attempt creating a domain model (all other attempts will be doomed to failure, likely as an anemic domain model).
Sounds pretty bad, to be honest. Still, somehow I am not convinced. The reason I am not convinced is very simple: complexity. Look at the quotes above, they both mention ADM being not half as bad for “not so complex” domains. But do you really want to have your domains that complex?
Complex systems tend to require lots of configuration glue to keep them together. They are hard to learn and require developers to understand the whole thing before they can become fully productive. In the real world, complex projects tend to grow larger and more complex, original designers move on or move up, new features and entities keep being are added, and eventually such projects turn into a Katamari ball.
Anemic Data Model, on the other hand, means that you have very simple data objects (if they grow too big or too complex it’s a sign that you need to split them) and a set of well defined interfaces for processing these objects. Instead of making your model more complex you separate components and make them interact using interfaces, shifting towards a loosely coupled model from a complex monolithic model.
It’s a bit of an old Unix paradigm: make one component do one thing really well, define it’s interface, interact with other components when you need to.
Loosely coupled projects are a lot easier to maintain, evolve, and scale. Simple data structures and simple interfaces allow for just that. If your project is getting too complex, figuring out how to simplify data structures and interfaces might be a better choice than working out a more complex data model.
P.S. This is one of the reasons why protocol buffer messages produced by proto-cs are declared as sealed. They are data messages, there is no need to inherit from them.
