We like Design Patterns. They make complicated things simpler. Our
brains are designed to tackle complexity with them. It is easier to
describe something with words "it's like that one thing that you know,
but with some differences" than describing it completely from scratch.
All frameworks that we use are full of Patterns and we understand them very well. Decorator here... Chain of responsibility there... Oh, and some old, nasty, huge and extremely overloaded Singleton over there - yup, we use it too... Piece of cake. This is our (developers) well known Domain. We are Domain Experts on that territory and we feel confident there.
The reality
But guess what - this is not the Domain that we are dealing with on daily basis (unless we are working on frameworks of course :P ). Our Domain, which we are struggling with, is about the business that runs our company. We don't need those mentioned Decorators and stuff.
At a glance, it looks like we can just live with some simple bags for data, called entities, mapped to database tables (the Anemic Model). I personally like to call them humorously Records - the great pattern that is borrowed from Turbo Pascal. I think, that Sławek mentioned about it couple of times (in polish). ;)
So, our entities have a bunch of getters and setters, they are managed by some Services/Managers/OtherFancyCalledStuffMakers without explicit boundaries, and eventually everything is connected to everything. We have beautiful and tasty spaghetti monster in our Version Control System and not a single pattern is in use in this "boring" Domain Model.
From the other side - isn't that great when it comes to talk about Patterns? We can push all this stupid Domain related stuff off to the side, call it "data" and go back to our safety zone. And once we are there - oh yes - we can finally talk about our well known Design Patterns! We can argue about differences between MVC and MVVM and our company's business model lays over there - alone in some dark package greatly called "domain". Probably quite sick because of his anemia...
Why we are letting the Model to rust in a such way? I can think of about five reasons.
2. We do not know Patterns
We cannot apply something, that we do not know. So here is the solution: read Eric Evans' book - Domain Driven Design: Tackling Complexity in the Heart of Software - there are a lot Patterns for Modeling the Domain (Building Blocks).
5. "No, and that's final!"
Well... If You are such an ignorant, then nothing will help You... You will eventually burn in hell. Just keep Your dirty hands far away from my codebase, and we will both be happy. ;)
PS.
Can You think of any other reason why we still do not like Patterns in the Domain?
All frameworks that we use are full of Patterns and we understand them very well. Decorator here... Chain of responsibility there... Oh, and some old, nasty, huge and extremely overloaded Singleton over there - yup, we use it too... Piece of cake. This is our (developers) well known Domain. We are Domain Experts on that territory and we feel confident there.
The reality
But guess what - this is not the Domain that we are dealing with on daily basis (unless we are working on frameworks of course :P ). Our Domain, which we are struggling with, is about the business that runs our company. We don't need those mentioned Decorators and stuff.
At a glance, it looks like we can just live with some simple bags for data, called entities, mapped to database tables (the Anemic Model). I personally like to call them humorously Records - the great pattern that is borrowed from Turbo Pascal. I think, that Sławek mentioned about it couple of times (in polish). ;)
So, our entities have a bunch of getters and setters, they are managed by some Services/Managers/OtherFancyCalledStuffMakers without explicit boundaries, and eventually everything is connected to everything. We have beautiful and tasty spaghetti monster in our Version Control System and not a single pattern is in use in this "boring" Domain Model.
From the other side - isn't that great when it comes to talk about Patterns? We can push all this stupid Domain related stuff off to the side, call it "data" and go back to our safety zone. And once we are there - oh yes - we can finally talk about our well known Design Patterns! We can argue about differences between MVC and MVVM and our company's business model lays over there - alone in some dark package greatly called "domain". Probably quite sick because of his anemia...
Why this happens?
Why we are letting the Model to rust in a such way? I can think of about five reasons.
1. We are not aware that we are missing Patterns in the Model
We
were taught to use Turbo Pascal's Records in Java, or C# and we did not
even think that this may be wrong. But guess what - You are reading
this, so You are now aware! ;)2. We do not know Patterns
We cannot apply something, that we do not know. So here is the solution: read Eric Evans' book - Domain Driven Design: Tackling Complexity in the Heart of Software - there are a lot Patterns for Modeling the Domain (Building Blocks).
3. We do not want to dig into the business Domain to find those Patterns
We
are software developers. That means we are creating software - this is
our Domain and we do not want to change our speciality. But just think
about it - after months of dealing with some specific business, we unintentionally
begin to understand it... We actually dig into it - like it, or lump
it, but once you are aware, You should start thinking what is good for
Your project...
4. "Nah... It won't work for us."
This
kind of thinking usually means, that You got used to doing things in
Turbo Pascal's way. You like Your comfort zone. Introducing Domain
Driven Design (DDD) requires changing the mindset and behaviors. (Of
course, there is a possibility, that Your Domain is so straightforward,
that simple CRUD will do the trick, but I think most of us struggle with
bigger systems.) So stop looking for excuses!5. "No, and that's final!"
Well... If You are such an ignorant, then nothing will help You... You will eventually burn in hell. Just keep Your dirty hands far away from my codebase, and we will both be happy. ;)
PS.
Can You think of any other reason why we still do not like Patterns in the Domain?
Comments
Post a Comment