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.
Related
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.
UML is a great language to model software for business requirements, but there is a growing community that points some disadvantages for some lacking features.
What are the most significant disadvantages that you find crucial for UML and what could it be a good alternative to solve this lacking features?
The biggest one is that it's yet another layer of red tape that gets in the way of just $#%$#% coding the thing and making it work.
The fact that people use it to "model software for business requirements", as you put it, and other such process-oriented claptrap. UML started out as a conventionalised way for programmers to communicate software to other programmers in a pictorial form. In that sense it's just formalised napkin-scribbling - and as such it is very effective. You can draw a UML class diagram on a whiteboard and I can understand it without quibbling over notation.
But somewhere along the line someone got the idea that a drawing notation could somehow be a process in it's own right, or at least a formal part of a larger process. And that's just silly. UML diagrams are a fine way to illustrate books, and quite useful as a means for engineers to scribble ideas back and forth. But that's where it should have ended.
I can say at least three:
It takes a lot of time to keep the diagram reasonable and synchronized with the actual code. UML diagrams don't run, but require a lot of time. So they are good only if your organization size can manage them
You cannot represent every condition in a sequence diagram. It's impossible if you want to deliver. So state diagrams should convey basic facts, not all the possible outcomes.
Good UML software costs money and it takes some time to master properly.
So, I think UML is good as a complementary documentation role, and only if the size of your organization allows it.
Solutions... well, in the end, diagramming is just a way to convey high level information to another person, in space or time (e.g. could be you in some year time). Extreme Programming shifts the burden of information retrieval from dead tree to living brain. Of course, it assumes that the living brain never forgets, and never quits. Extreme programming uses redundancy to reduce the impact of such occurrences. In a large company, a strong layoff round could wipeout entire teams, so storing information into brains can be risky. On the other hand, large companies have human power to waste, hence the diagramming.
Also, as WDuffy points out, if you are a designer, and you have to communicate to a team of programmers what they have to implement, it's much easier to use a UML diagram. Of course, a small company with a small team has generally small goals, and you can organize people with a different style. A small company UMLing will only produce UML diagrams of their revolutionary product, and then it will be bankrupt.
UML is not good nor bad. It can be a good tool, but it must be used in the proper context.
Lacking features?
well, I found that UML is strongly aimed at an Object Oriented vision of the world. Our company mainly developed in python, with a strong focus on module level routines. Objects were lightweight data containers, but all the logic was done at the module level. It's difficult to properly model this implementation style at the UML level, unless you resort to some "hacks" in the terminology. I guess it's difficult to model in UML for functional or procedural languages.
Another thing I find annoying is the assumption of use case modeling as a diagram. My experience is that the best way to convey a use case is to write a short story or a short code tingling the feature you want to convey. The story should be short, one page maximum.
This approach has two advantages: if your story is a written prose, the Q/A team can read and test it easily. If your story is code, you can put it as a functional test and let it run during the night. A diagram does not satisfy any of these value added needs.
One issue with UML is due to its universality: things in UML cannot be always implemented directly in the target language, or some languages have capabilities that cannot be expressed in UML. So it can be better to know the implementation language beforehand, which restrain its universality.
See also the criticisms section on UML wikipedia page:
Standards bloat
Problems in learning and adopting
Cumulative Impedance/Impedance Mismatching
Dysfunctional interchange format
It's not Agile
What should have been the last word on UML was written by frustrated student "Candide Smith", well, really Eiffel author Bertrand Meyer.
Another disadvantage of UML is that it tends to overemphasize design, which can lead to 'analysis paralysis' (people over-analyze their problem) and feature creep (loosing sight of the actual problem). A UML design can only take you so far in solving a problem, and you have to be careful to jump into the code soon enough (but not sooner ;-).
UML is somewhat less applicable to the brave new world of loose typing and NoSQL databases. It has OO ideas of Class as a data structure rather than classification embed in it.
Another disadvantage, although not self-inflicted, is that it doesn't explicitly to facilitate abstraction. Everyone I know uses UML tools for more abstract modelling, but the way standards are written that is not obvious.
Another problem with UML (and big design up front in general) is that it's sometimes hard to anticipate all the nitty gritty implementation problems that you'll run into that may affect your design until you actually start implementing something. Granted, I'm a bioinformatics research programmer that works on small one-man projects, but I don't even believe in any design up front, at least for small projects. I believe in the following:
Make it work. (Just get a prototype up and running that has all the basic functionality, no matter how much it sucks. This forces you to see all the little nitty gritty details that might not come through in a formal analysis. Having an actual implementation of your idea makes it easier to see whether the idea was even really worth doing in the first place or whether it should be scrapped altogether.)
Make it right. (Only now, when you have a working prototype and you know that all the nitty gritty implementation problems are at least in principle solvable do you worry about good design. Refactor the heck out of it to follow good programming practices, reduce coupling, do proper error handling, yada yada yada.)
Make it fast. If it's application code, you'd better have proof that you've found the slow part. If it's generic library code, you'd better have good reason to believe that the piece of code could reasonably be the slow part in some use case for the library, i.e. don't optimize a function that noone would ever call in a loop.
For Class Diagrams in UML it only makes sense to use them if there is automated way to generate code directly from diagram. I have implemented such UML editor tool based on 4-tiers meta levels recommended by OMG (Object Management Group) and we had great success using UML in team of 5 devs over 2 years doing around 20-30 architectural iterations. The diagram was the root artifact of automated build chain making impact on hundreds of derived artifacts, APIs, generated Docs, DDLs, projects, tests etc.
So by itself UML in Class Diagrams part is great "programming" language if you actually do programming in it.
For Class Diagrams in UML if it is not translatable in automated way, then its fail.
What are the best modeling languages to know. What are the most important things to know about the modeling languages. Espically BPMN as it seems like an interesting topic.
I think BPMN may have some use in companies that have very formal approach to writing specifications, the same kind that would use UML for describing every aspect of simple cancel button. Majority of developers heard only of UML and even that is not really well understood, nor employed extensively in practice.
As usual, the really important questions you want to ask are:
What do you want to model?
Who are you writing this for?
If you are doing this for yourself, you may just as well use your own notation made up ad hoc. It will be faster than going through pages of spec written by experts from OMG (Object Management Group, though Oh My God is not a bad explanation either ;-)).
If you need to share the doc with others, UML seems like a good choice. It is sort of understood by the community and all ambiguity you can always rewrite in plain English.
If your client requires BPMN, then well -- read on it and learn it well. Maybe hire consultants to verify if you are doing it right. If you are not required by contract to use it, then -- for Gods sake -- go write code and document it well and not spend too much time pondering which modeling thingy is most hip now. None isn't and none will be any time soon.
IF you are involved in a ERP implementation, getting the business processes right upfront can save you a lot of trouble down the road.
Organisations know surprisingly little about their inner workings and it's the ERP developers that get the beating when their software doesn't fit to the company. If you can soften that clash of cultures by doing a bit of proper analysis before the development phase, then you are doing the right thing.
BPMN is really one of the easiest and most simple methods there is for the job. Making up your own way of describing Business processes is just reinventing the wheel. Check out some of the free tools on the market; BizAgi for instance.
Good luck.
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?