Ive heard allot about sizing up Microservices using bounded context from DDD. Any ideas what this actually means?
thanks
goaths
I have a guess, that you're heard a reference on the talk of Eric Evans on GOTO 2015 about strategic design and microservices, so you may want to watch this capture at first:
https://www.youtube.com/watch?v=yPvef9R3k-M
This topic also was covered by him in a further talk:
https://www.infoq.com/presentations/ddd-microservices-2016
Related
There are a lot of resources out there that address a couple aspects of ES, but most of them are pros/cons list or example snippets. Terms, such as projection, apply, replay are also used (mostly) without explanations or in slightly different contexts.
The best sample implementation with corresponding documentation and extra resources is the CQRS Journey from Microsoft, and one can learn from it a lot, but it is not authoritative.
The closest to an informal spec I could find is Leif Battermann's concise summary, but his entire site has been down for a couple weeks now.
It may be that such comprehensive guideline does not exist, because it is a concept that became popular, people picked it up, started using it as they saw fit and no one will ever agree on the details anymore.
UPDATE (2/16/2018 11:03)
I missed Greg Young's (who coined the term CQRS) Event Centric: Finding Simplicity in Complex Systems book somehow. Would this be a publication to ES as Eric Evans' book is to Domain-Driven Design?
The closest thing to what you are looking for is probably Martin Fowler's 2005 essay; Martin's description predates Young's introduction of DDDD/CQRS by a few years.
Would this be a publication to ES as Eric Evans' book is to Domain-Driven Design?
No; among other things, Evans actually wrote the blue book. Event Centric has not been written (as of October 2017).
I might have a silly question about DDD:
Are there any disadvatages of DDD generraly? I mean, besides of using it when it is not necessary, or needed. (e.g. small/not complex projets)
Thanks
It is very easy to do it wrong.
Eric Evans has said in a JavaOne presentation that DDD is best applicable when there is a lot of business domain complexity. Moreover, he explicitly states that DDD is not suitable for problems where the is substantial technical complexity but that has little business domain complexity. An example of the later is an embedded system with very simple inputs (possibly independent of the number of states it possesses) while simultaneously presenting a lot of technical complexity (in terms of getting the hardware to work.)
How we go about quantifying a lot or a little, that's an open subject. But the narrative should work as a guideline of when and where DDD is best applicable.
-- edit --
I got the video presentation through Emule, and I've never been able to find that same lecture on youtube or similar video venues.
I found this discussion of DDD in the Microsoft Application Architecture Guide to be helpful in understanding the challenges of that particular style:
As the core of the software is the
domain model, which is a direct
projection of this shared language, it
allows the team to quickly find gaps
in the software by analyzing the
language around it. The creation of a
common language is not merely an
exercise in accepting information from
the domain experts and applying it.
Quite often, communication problems
within development teams are due not
only to misunderstanding the language
of the domain, but also due to the
fact that the domain's language is
itself ambiguous. The Domain Driven
Design process holds the goal not only
of implementing the language being
used, but also improving and refining
the language of the domain. This in
turn benefits the software being
built, since the model is a direct
projection of the domain language.
In order to help maintain the model as
a pure and helpful language construct,
you must typically implement a great
deal of isolation and encapsulation
within the domain model. Consequently,
a system based on Domain Driven Design
can come at a relatively high cost.
While Domain Driven Design provides
many technical benefits, such as
maintainability, it should be applied
only to complex domains where the
model and the linguistic processes
provide clear benefits in the
communication of complex information,
and in the formulation of a common
understanding of the domain.
At an italian conference, I talked about the topic (see these slides).
DDD projects require domain experts that are often expensive to hire, since they hold valuable knowledge (read, if you don't need a domain expert, you don't need DDD).
Moreover DDD requires strong skills on the modeler side. In particular they have to be:
Humble, since they have to accept their ignorance and learn from an expert
Really skilled in OOP
Diligent, since they have to track decisions
Comunicative, since they have to explain the domain to the other devs (even through documentation)
Finding such developers can be much more expensive than expected, since you can really know that they are good at the job after some months of trials.
Martin Fowler in his "PoEA" book has a great discussion of when and what domain logic patterns to use.
For instance, simplest pattern, Transaction Script, involves no domain model.
What is the best way to start Domain Driven Design?
What are the recommended resources?
EDIT:
I mean, I'd like to know how to start learning DDD (the same way as to start TDD by reading K. Beck).
There's a really big book available on domain driven design, which was brilliantly abridged and made available as a free download here:
http://www.infoq.com/minibooks/domain-driven-design-quickly
To start "doing" domain driven design, you just need to follow the points in this book. Share a language with the business, create objects that represent something that the business would recognise and so on.
It is more difficult to get in full swing on large existing applications (but not impossible) but if you are writing something new, that's a great opportunity to go at it 100%.
The definitive book on DDD is Domain-Driven Design: Tackling Complexity in the Heart of Software
However its a book that takes some gestation that is best backed up with practice and observing how experienced DDD'ers think.
The site http://domaindrivendesign.org/ has some excellent resources including example projects. I also find it useful to trawl the various open source code repositories such as GitHub, Codeplex and SourceForge for projects that use DDD
Good luck on your DDD journey, its a long road without a turn!
My personal advice is to forget the "DDD Quickly" book and go straight to the "Domain-Driven Design: Tackling Complexity in the Heart of Software" book from Eric Evans. I'd also suggest not to read the book in the original order, but to read the intro and then move to the Strategic Design section, and only then go back to the first part of the book. You'll discover that there's more to DDD than a collection of patterns.
However, after the book has been published there's been some evolution in the DDD community (have a look to this video as a refresher). A new pattern Domain Event has been published, and many alternative supporting architectures have been discussed: CQRS and Event Sourcing above all.
Tomorrow i need to show small presentation about DDD approach.
It should contain 2 main points:
"What is Domain Driven Design?"
"How can we use it?"
I would be glad if i could see some ideas how to 'implement' first point of my 'presentation interface'.
Asking because I'm not making presentations everyday and i`m little bit confused.
Somewhat hard to understand whether your problem is a lack of DDD knowledge, or just how to present it.
"What is Domain Driven Design" - grab a good overview from http://www.infoq.com/minibooks/domain-driven-design-quickly
"How can we use it". You can't really just "use it". You must identify the parts of it that makes sense for your business.
You can take advantage of the big focus on understanding and modeling the business, and creating a common language in speech, code and documentation.
You can use ideas related to software architecture, like using repositories, entities and value objects.
You can take note of the principles for good design and code quality, like intention-revealing interfaces, side-effect-free functions, etc.
You can try to pass on knowledge of refactoring, and strategies relating to larger systems.
Some are low hanging fruit in concept understanding, others are hard to impose without personal interest.
Amis,
Is to translate the current slide to your needs (its in portuguese-brazil) -> Slide
Explain that DDD isnt a tech or methodology, but is more like an approach that gather various concepts, techniques and principles with focus on domain logic.
Explain about ubiquitous language, Layered architecture, Domain Patterns, and diffs about current approach and ddd approach, later on enlighten then with the benefits of using DDD over the current methods and add a conclusion on your presentation..
Hopes it helped ya.
This mind map sorted my mind.
So what are the UML diagrams (if any) Stackoverflow has been using for documentation and/or for communication with developers?
From what I see, Stackoverflow is something original that also provides rich user experience.
Just wondering what does it take (what helps) to realize a great thought into real life? I`m just a student graduating seeking for advice/experience/suggestions/examples from senieors.
How much these diagrams help in real life and in what volume (the diagrams), I wonder...
UML is a "standard" defined way to communicate something. Being well defined it removes ambiguities that may exist when using other methods.
Having said that I don't use them with my team. I find that the overhead in doing proper UML is too high.
Since I work in a small team (about 5 people) that works in the same location, we'll often sit down and sketch diagrams in discussions. If we need to reference these diagrams, we'll scan them and post them to a repository for later reference.
UML is probably more beneficial in teams that don't communicate well, and may not be co-located.
I really expect all my co-workers to be able to read a UML diagram properly; it's become a kind of universal language for speaking about OO designs.
Back in the days of big design we made tons of models that we put in big binders. Especially sequence diagrams were really nice for detailed designs. These binders would look really impressive on some shelf, but it turned out most of the value in these models are in the process of making them
So now we mostly just draw boxes with lines between them on whiteboards. But whenever we resort to explicit notations to be precise, it's always UML. Usually we photograph them with our phone if they seem like they're worth keeping. Sometimes we just leave them on the whiteboard because they kind-of burn into the whiteboard if they stay there for some days ;) [And you have to be especially daring to use the smelly strong cleaner]
I read an article in Inc Magazine about this site, which is how I found out about it. Apparently very little formal process was followed. Basically, the guys who did it were just really good. My money is also on no UML. I wonder if they use OO?