The document describes 3 easy steps to drive your DBA crazy:
1. Start with a small project that grows increasingly complex without oversight, making someone responsible for the growing complexity.
2. Engage in confusing and nonsensical conversations about the project that frustrate the DBA's attempts to understand it.
3. Repeatedly violate the DBA's authority over and ownership of the database through dangerous or prohibited actions, disrespecting the DBA's expertise.
73. Aggregate modeling Hp (from
UDI Dahan):
Group words according to the
conversaRons you use them in,
inclute aBributes, not only
classes. Different Stakeholders/
Domain Experts will use different
words to fulfill different goals
And that’s the company I started one year ago.\n
Think of “So spoke zarathustra” as a soundtrack here :-)\n
\n
It’s at the center of every operation. Is the cornerstone of every IT service. One cannot even dream of an IT service without it.\n
\n
Enter Jack, our DBA or “Data Oriented Person”. He’s the person you’ll have to argue with at a given moment, when you try to build something different from the same old stuff.\n
And that’s the realm of Jack. The E-R Diagram, where complexity means power. \n
Is this diagram really useful? Yes. Perfect for covering the table. Developing software is another thing.\n
\n
Jack is the person to call to solve complex and intricated problems. The fact that maybe he’s also the origin of complex and intricated problems is often obscure to the business side of the company.\n
Jack is the person to call to solve complex and intricated problems. The fact that maybe he’s also the origin of complex and intricated problems is often obscure to the business side of the company.\n
This used to be a question that struck me after giving a talk about CQRS and DDD. A guy in the audience asked me how did I face this problem.\n
And honestly I didn’t know.\n
But even more honestly, I’ve never had the chance to face a query with 16 joins. Not in the applications I’ve designed. I suspect this has something to do with my design style.\n
Because instead of starting the application from a data model, I normally start designing it around a domain model tailored for specific use cases.\n
\n
Many times, the work of the Data-Oriented Person is obscure to me. Sometimes I get presented with a Data Model even if I’ve never asked for one. Sometimes I get forced to use one. More often than not the DBA needs to know what our team is doing while we cannot know what the DBA is doing.\nSometimes it’s definitely worth a look.\n
Ans sometimes he’s just trying to solve the wrong problem.\n
That’s one nasty thing we might encounter while dealing with legacy data model.\nIt takes half a movie to realize that redrum is really murder. But DBA love encodings and the like.\n
That’s one thing Data Oriented People love. Giving conventional names to things.\nPicking the names from the domain is not an option.\n
But for Domain Driven Design practitioners, this line of code SCREAMS!\nWhat does this code mean?\n
And of course this means something for the creator, but for us, poor explorers of legacy mess the mening is obscure.\n
Asking for a different coding convention, might result somewhat unpolite, sometimes. Remember, conventions are always clear for the creator. And the creator ha probably been promoted...\n
Yes, that’s what we want to do in DDD. We want/need to speak same the Ubiquitous Language in every aspect of software development, with every role involved. It works. It’s cool. It’s fun.\n
But for some reason, DBAs are untouched by this approach. And they don’t care.\n
Apparently they have good reasons for not changing theis approach.\n
And to be effective in such a workplace, one needs to learn all the different tips and tricks of the legacy system. Becoming part of the legacy.\n
Is this the right complexity to learn?\n
I bet not. We are wasting our time on accidental complexity. One that’s not part of the domain, but part of the (wrong) solution somebody designed before us.\n
But this complexity has costs. Few measure that, but have a look to how much time is necessary for a newcomer to be productive in such a scenario. You’ll have interesting results. Disappointing, I suspect.\n
The lesser, the better. But what about your workplace?\n
And ...let’s sat that. Business people are not sadistic monsters. They are simple minds after all. They probably can’t imagine an incredibly complex requirement. It’s our solution that’s messy.\n
It’s a software architecture problem and it’s an organization problem. Hope nobody gets offended here, but this is an organization which is 2000 years old. Plenty of rules and dogmas, make it roughly impossibile to change without getting into contraddiction. To avoid contraddictions ...the organizations stand still.\n
Some things are definitely harder to change.\n
Let’s talk about something different. About sharing the things you care about.\n
This is one little cheap thing you don’t share. I wonder why?\n
That’s another thing you don’t share. You can show it to your friends but they’re not allowed to touch it.\n
That’s not different for your Harley Davidson. Friends can have a look. Good friends can even touch it. But nobody can ride it except you.\n
That’s the same with the operating room. Surgeons do not share it. Nor do they share their tools. They need a sterile environment. You don’t turn a little hospital into a bigger one by putting the operating room in a large shared open space. And what used to work in a little hospital is not necessarily good for a bigger one.\n
And that’s the one. You don’t share your database. Yes, you got it: you don’t share your database.\n
I mean it. No one reads from my database. I will change table names and schema. Without dropping you a note. I don’t care if this is causing a bug in your system. Your fault. This is MY database and I am the only one allowed to read and write. Tomorrow it will be different, and next week it might be a NoSQL. But will still be MINE.\n
Enter the DDD concept of Bounded Context, that’s where our database lives. We need to be coherent and consistent with the language and this is a viable strategy only if we don’t share our database.\n\nOf course, there might be data sharing. But in a format that’s designed for data sharing. With different evolution needs.\n
What does it mean ...YOUR database? Every database is mine. Following my conventions.\n
Let’s see it from another perspective\n
This looks like a state diagram, something our analyst might have sketched to illustrate a business process. So looks like an Order is passing through many different phases.\n
But that’s not an Order even if it might refer to the same concrete entity, not all the workflow needs to map to the same class.\n
If we do that ...that’s the mess we’ll generate!\n
And we’re not even in the same aggregate. But to be clear about this we need to clarify a little more about what a aggregate is in DDD\n
The next key DDD building block is Aggregates. The Domain Model isn’t flat. Some links are stronger than others (and UML doesn’t really help much in rendering it).\n\nIf we start considering consistency and behaviour as the primary drivers for modeling our domain we’ll end up with something quite different from a 1-1 projection of the data model.\n
The next key DDD building block is Aggregates. The Domain Model isn’t flat. Some links are stronger than others (and UML doesn’t really help much in rendering it).\n\nIf we start considering consistency and behaviour as the primary drivers for modeling our domain we’ll end up with something quite different from a 1-1 projection of the data model.\n
A model is a tool to solve a problem. We have different stakeholders/roles here each one with a different problem. Are we really thinking that a single model will solve them all?\n
In fact different goals will be the territory of different domain experts speaking their language. Which is tailored around their purpose. To solve different problems we’ll have multiple models.\n
Are you prepared for that?\n
Yeah, duplication. The root of all evil. Are you ready for that?\n
You obviously don’t like duplication. Because you’re adhering to DRY.\n
Everybody apparently is following DRY. So I took a look to the original statement. Which is a little more sophisticated than duplication is evil.\n
Read again Any Hunt’s definition, and read also the interview at http://www.artima.com/intv/dry.html\n
\n
If it’s just me... I don’t repeat myself. If it’s just my team, then we communicate and we share a vision about our system. But if it’s two or more different teams then the cost of communication is significant, and sharing might not be the most efficient way to deal with this specific issue.\n
How big is the system we’re talking about? Can’t it be our bounded context?\n
Sharing a piece of code means coupling. If you reuse my piece of code then coupling is introduced in the system. When I refactor I’ll need to double check against external test suites also. Flexibility has a higher price, and sometimes I am not willing to pay for it.\n
Yes, we don’t need many justifications...\n
Because data and behaviour are different. And data can be the same, but with different roles within the system.\n
For example, in this case we’ll notice some duplication, related to customer. But lifecycles of the customer and of the order are different. If a customer moves, we don’t want to have all of our past orders changed, at the same time if an order needs to be canceled, we don’t want the user to get down the sink as well. \nA little duplication is what allows aggregate lifecycles to be independent.\n
If we don’t want to have any duplication at the data layer... that’s the mess we’ll end up living in.\nIt’s called Hell.\n
Focusing on the language can be a good technique. And rarely aggregates come from our legacy data model. You’d better forget about it. And start thinking from scratch.\n
How to coordinate communications between aggregates? Well ...DDD now is focusing on Domain Events.\n\n
Domain Events as a communication means between aggregates really simplify things a lot, even at the conceptual level.\n- Do they really belong to the same transaction?\n- Would you want the order to roll-back if you are unable to process the discount for the next order by the same customer?\n\n... but really, how the two things should be related, ...is a business choice! We just have more and more possibilites in our arsenal.\n
Surprisingly, but Udi Dahan and Greg Young in their speeches at last DDDx put the paper-based system at the center of their vision. If a complex system could work without computers ...there must be a reason for that. Sometimes computers just overloaded the systems with more unnecessary complexity.\n
There might be inconsistencies in the data or between the data and the paper. In many system (especially those data-entry based) the paper used to be the Single Source of Truth, but larger integrated systems Events are probably a better candidate.\n
There might be inconsistencies in the data or between the data and the paper. In many system (especially those data-entry based) the paper used to be the Single Source of Truth, but larger integrated systems Events are probably a better candidate.\n
You mean the Database is not the center of things anymore? Not here!\n
So Jack is going to be Angry and trying to rise some consistency or security issue.\n
But since we did our job well, he’ll be thwarted by our system performances, and the old architecture will look like an ancient nightmare....\n
\n
That’s not the way we’re supposed to work.\n
We strived to establishe a good collaboration with the domain expert...\n
\n
There’s not a rule. Talk with the people. Some of them are nice. Understand their needs.\n
Do not start from huge refactorings, unless the problem is really small (only ...the legacy solution is large)\n
Do not take any unnecessary risk. Keep backups, and ensure security policies are respected.\n
You’re having fun, and they’re not. Nobody likes to be treated like the old boring guy. You’re doing something new, involve them.\n
Be a fair person. Even if you don’t like their approach do not surprise them with nasty moves.\n
So that also Jack might find a happy place in the picture.\n