Drive your dba crazy in 3 easy steps

65,278 views
63,330 views

Published on

It’s there, it’s always been there. And you know that if you want to do Domain Driven Design seriously, you’ll have to challenge some of the assumptions that have been around for so much time that everybody forgot we were able to deliver working software also without them.
Of course, not everybody’s going to like it. Oh well ...that’s life!

Published in: Technology
6 Comments
15 Likes
Statistics
Notes
No Downloads
Views
Total views
65,278
On SlideShare
0
From Embeds
0
Number of Embeds
111
Actions
Shares
0
Downloads
134
Comments
6
Likes
15
Embeds 0
No embeds

No notes for slide
  • \n
  • \n
  • 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
  • \n
  • Drive your dba crazy in 3 easy steps

    1. Driving
your
DBA
crazy
 in
3
easy
steps a
scary
story
by
@ziobrando
    2. About
meIn
the
IT
field
since
ZX
SpectrumGenerally
in
large
scale
projects
(I
might
be
biased)Freelance
consultant:
NotOnlyCodeTrainer
(Freelance
&
Skills
MaBer
+
Zenika)Technical
WriterBlogger:
h?p://ziobrando.blogspot.comTwiBer:
ziobrando
My
e‐mail:
alberto.brandolini@gmail.com
    3. @avanscopertawww.avanscoperta.itavanscoperta.wordpress.comalberto.brandolini@avanscoperta.it ©
Alberto
Brandolini
2009
    4. It
started
small
    5. It
grew
    6. It
became
more
and
more
complex
    7. Somebody’s
goBa
be
 responsible
 for
that
    8. Useful
    9. but
sHll...
    10. When
it
comes
to
run
a
query
with
16
joins
you’re
 the
person
to
call...
    11. When
it
comes
to
run
a
query
with
16
joins
you’re
 the
person
to
call... You
can
say
it
 loud,
pal
    12. So
how
do
I
design
a
query
with
16
joins?
    13. I
don’t
know
    14. I
don’t
    15. I’d
rather
explore
the
domain
    16. While
Jack
works
    17. ...in
bulk
mode,
of
 course
    18. Type
1
and
Type
2
    19. int Type = 1;
    20. int Type = 1; st h is a td oe !!! W h ea n?? lin em
    21. if
Germany
is
Type
6
and
Wednesday
is
type
 A
then
type
1
should
 be
...Red
    22. So you’d use a “readable data”, ... are you a communist or a lady?
    23. Analyst Domain Expert Developer DeveloperInterviews Ubiquitous Language Whiteboard discussions Application Code Specs and Test Code documentation ©
Alberto
Brandolini
2011
    24. Analyst Domain Expert Developer DeveloperInterviews Ubiquitous Language Whiteboard discussions SQL Application Code Specs and Test Code documentation DBA ©
Alberto
Brandolini
2011
    25. So You want to speak the Ubiquitous Language, you scumbag? ©
Alberto
Brandolini
2011
    26. So You want to speak the Ubiquitous Language, you scumbag? The only ubiquitous Language is SQL! Every Database speaks it! ©
Alberto
Brandolini
2011
    27. What is a Type 1 you scumbag?!A Type 1 is a Type 1, sir! I can’t hear you!!
    28. What
is
the
complexity
 you’re
tackling?
    29. Accidental Domain
 Complexity Complexity Conventions Behaviour Primary Keys SemanHcs Joins Language Legacy encoding Conceptual
integrity Replicas Context
BoundaryStored procedures Domain
Events Triggers
    30. How
much
Hme
is
needed
for
a
newly
hired
developer
to
 start
being
really
 producHve?
    31. How
many
things
we
need
to
know
before
 contribuHng
to
the
 system?

    32. A
new
business
requirement
impacRng
 the
applicaRon
in
20
 different
points
is
an
 architecture
problem
    33. unsurprisingly,
the
more
rules
you
have,
the
harder
it
 is
to
evolve...
    34. You can give your heart to DDD,but your ass belongs to the DB!
    35. Things
you
don’t
share,
even
with
your
best
friend
    36. Your
Toothbrush
    37. Your
Comics
CollecHon Your
Database
    38. Your
Harley‐Davidson
    39. The
operaHng
room
    40. Your
Database
    41. THIS DATABASE IS MY DATABASE TRESPASSERS WILL BE SHOT SURVIVORS WILL BE SHOT AGAIN ©
Alberto
Brandolini
2011
    42. Bounded
Context‐ Context:
a
seSng
where
a
word
 Shipping appears
that
determines
its
 meaning‐ A
porRon
of
the
system
where
the
 Ubiquitous
language
is
consistent Payment ©
Alberto
Brandolini
‐
2010
    43. He’s
probably
not
going
to
like
it ©
Alberto
Brandolini
2011
    44. The
infinite
workflow
    45. add/remove Item Ready for Open finalize Closed select DeliveryAddress ShippingMode Selection select Shipping Mode Ready for Ready for Shipped ship pay Delivery Payment deliver Delivered return Returned ©
Alberto
Brandolini
2011
    46. Not
the
same
EnHty
    47. Not
the
same
 Aggregate
    48. Aggregate ©
Alberto
Brandolini
‐
2010
    49. AggregateA
group
of
objects
that
naturally
belong
togetherUnit
of
consistency
in
the
domain
modelupdated
in
the
same
transacHondeleted
togethertransferred
together ©
Alberto
Brandolini
‐
2010
    50. Aggregate <<Entity>> <<Value Object>> Order LineItem date goodsA
group
of
objects
that
 customer amount quantity notesnaturally
belong
together ... subtotal() update() ... close()Unit
of
consistency
in
the
 ship() ...domain
model <<Value Object>> <<Value Object>> Money Customer currencyupdated
in
the
same
 name amount surname address plus(Money other)transacHon minus(Money other) ...deleted
togethertransferred
together ©
Alberto
Brandolini
‐
2010
    51. Customer add/remove Item Ready for addTocart Open finalize Closed select DeliveryAddress ShippingMode Selection select Shipping Mode Ready for Ready for Shipped ship pay Delivery Payment deliverLogistics Financial Dept Delivered return Returned Customer Care ©
Alberto
Brandolini
2011
    52. Different
Domain
Experts Different
Goals Different
Language Different
ModelsDifferent
Bounded
Contexts Different
Aggregates ©
Alberto
Brandolini
‐
2010
    53. And
this
will
lead
to...
    54. DuplicaHon
    55. Dont’
Repeat
Yourself
    56. “Every
piece
of
knowledge
must
 have
a
single,
unambiguous,
 authorita;ve
representa;on
 within
a
system” Andy
Hunt
‐
The
Pragma;c
 Programmer
    57. The
duplicaHon
dogma
    58. What
does
YOU
mean?
    59. The
cost
of
avoiding
duplicaRon
increases
 with
scale
    60. What
does
within
a
 system
mean?
    61. Consider
coupling
also
    62. ...
and
by
the
way,
we’re
not
violaHng
the
 DRY
anyway... :‐)
    63. Data
DuplicaHon
!=
behavior
duplicaHon
    64. MulHple
aggregates Money currency amount plus(Money other) minus(Money other) ... <<Entity>> <<Root>> <<Value Object>> <<Entity>> <<Root>> Order LineItem Customer date goods name customer quantity surname amount notes address ... subtotal() ... update() ... updateDiscount() close() ... ship() ... shipping address <<Value Object>> CustomerData billing address name surname <<Value Object>> Address <<Value Object>> street city country zipcode ©
Alberto
Brandolini
‐
2010
    65. Tha g at’s g re M ga Y te? ...
    66. 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
    67. Events
and
aggregate
coordinaHon ‐ OperaRons
spanning
mulRple
 aggregates
shouldn’t
be
in
the
same
 Unit
of
Work
‐ CommunicaRon
between
aggregates
 <<Domain Event>> is
inherently
asynchronous OrderPurchased‐ Domain
Events
as
a
communicaRon
 order where mechanism when amount ‐ from
the
outside payment method ‐ among
aggregates ... ... ©
Alberto
Brandolini
‐
2010
    68. Asynchronously
responding
to
events <<Domain Event>> OrderPurchased order where when amount <<Entity>> <<Root>> payment method s u bs <<Entity>> <<Root>> s to ... cri b Order su b s c ri be e s to Customer date ... name customer surname amount address ... ... onPurchaseEvent(...) onPurchaseEvent(...) update() updateDiscount() close() ... ship() ...‐ Don’t
forget:
Business
rules
everything!!! ©
Alberto
Brandolini
‐
2010
    69. The
paper‐based
systemMany
business
pre‐date
computersTransacHons
are
oeen
NOT
a
business
concernData
might
be
stale...
accept
itASK
the
Business
    70. ! Single
source
of
truth? ©
Alberto
Brandolini
‐
2010
    71. ! Single
source
of
truth? ‐ Once
it
used
be
paper...
 ©
Alberto
Brandolini
‐
2010
    72. ! Single
source
of
truth? ‐Once
it
used
be
paper...
 ‐ now
the
best
candidate
is
Events ©
Alberto
Brandolini
‐
2010
    73. That’s
gonna
make
him
REALLY
angry ©
Alberto
Brandolini
2011
    74. ©
Alberto
Brandolini
2011
    75. ©
Alberto
Brandolini
2011
    76. Does
it
really
have
to
 end
like
that?
    77. E’
necessario
un
processo
di
 sviluppo
agile,
che
permeBa
di
 raccogliere
il
feedback
di
utenH
e
 Our
goal
is
to
establish
a
creaHve
domain
experts,
in
iterazioni
brevi. collaboraHon ©
Alberto
Brandolini
2009
    78. We
did
it
with
the
worst
Domain
Experts...
can’t
we
do
it
with
the
DBA? ©
Alberto
Brandolini
2009
    79. We
did
it
with
the
worst
Domain
Experts...
can’t
we
do
it
with
the
DBA? ©
Alberto
Brandolini
2009
    80. Humble
Tips:
    81. Personality
Rules
    82. Start
small
    83. Work
Safely
    84. Share
the
fun
    85. Behave
    86. Thank
youalberto.brandolini@avanscoperta.it hBp://ziobrando.blogspot.com twiBer:
ziobrando

    ×