|
Is being cremated my last hope for a smoking hot body?
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
I know a place downtown that performs a pretty good creamation at a decent price!
... such stuff as dreams are made on
|
|
|
|
|
Well, the last smoking hot body was Cinder-ella so it makes sense.
DURA LEX, SED LEX
GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X
If you think 'goto' is evil, try writing an Assembly program without JMP. -- TNCaver
When I was six, there were no ones and zeroes - only zeroes. And not all of them worked. -- Ravi Bhavnani
|
|
|
|
|
Embalm, cremate, and bury. Take no chances! 
If you have an important point to make, don't try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time - a tremendous whack.
--Winston Churchill
|
|
|
|
|
Are you allowed to smoke outside?
In Word you can only store 2 bytes. That is why I use Writer.
|
|
|
|
|
A cannibal who likes BBQ might provide you with one.
Mongo: Mongo only pawn... in game of life.
|
|
|
|
|
Anybody using Domain Driven Design as the main design methodology in their business - any experience (pro or con) to share?
|
|
|
|
|
Actually, yes. At this very moment, but there are no war stories yet. I have not been working on this project for too long yet.
And for a second I feared you were asking about Dalek Dave's Donuts.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a f***ing golf cart.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
If software development were a circus, we would all be the clowns.
|
|
|
|
|
Dang! You beat me to it. I was gonna say:
We haven't even used DD since he left us.
... such stuff as dreams are made on
|
|
|
|
|
And I would not put it beyond him to have given up politics in favor of producing and selling donuts.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a f***ing golf cart.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
If software development were a circus, we would all be the clowns.
|
|
|
|
|
Would be a step in the right direction.
... such stuff as dreams are made on
|
|
|
|
|
Would you eat sausage donut from CMOT Dibbler Dave?
|
|
|
|
|
|
I don't quite see the worrysome part...
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a f***ing golf cart.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
If software development were a circus, we would all be the clowns.
|
|
|
|
|
DD is clearly branching out into the Policeman's favourite food, in hopes of using them to force an successful outcome in his next election attempt!
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
I suppose it's a stupid question, but isn't DDD rather implicit? I mean, if I'm asked to write software for an ATM (the domain), I'm not going to write software for some other domain, like landing the shuttle, right?
From Wikipedia:
- placing the project's primary focus on the core domain and domain logic;
- basing complex designs on a model of the domain;
- initiating a creative collaboration between technical and domain experts to iteratively refine a conceptual model that addresses particular domain problems.
Isn't that defacto? How would you do anything other?
Marc
|
|
|
|
|
I suppose the key differential is really domians rather than one domain - i.e. splitting your application/system up (even at the analysis stage) into logical business domains and only allowing communication between domains through well defined channels.
So - not one big data model to rule them all.
|
|
|
|
|
Duncan Edwards Jones wrote: i.e. splitting your application/system up (even at the analysis stage) into logical business domains and only allowing communication between domains through well defined channels.
Aye matey, that be the ticket.
And amusingly, when doing just that (working with different hardware is one way to easily define domains) and having created a plug-in architecture with a multi-threading capable publisher-subscriber as the communication channel, the CTO said it was too complicated for the junior devs to maintain, and code must be maintainable by junior devs. So it got tossed out, replaced by a monolithic architecture that, granted, used streams for communication, but lost all capability for logging, threading, modularity, unified exception handling, etc.
Which is why tomorrow is my last day at that job! ![Jig | [Dance]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/jig.gif)
Marc
|
|
|
|
|
Hopefully it's opposed to CDD (Consultant Driven Development)
|
|
|
|
|
 Yes, Marc. That was exactly my reaction.
We think a software project is all about applying the best technology and practices, but it's first and foremost an educational exercise in context modelling - within us.
We have to build the contexts in our minds, then manifest them in the design structure.
That's what all those pesky things like specs, use-cases and design documents were intended to accomplish in the old waterfall methodology.
Yes that methodology is dated. It is plodding and meticulous work and management really never saw the profit in taking all that time to essentially write documents, but it ensured at least that the people coding knew what the elephant they were doing and what the elephanting goal was!
LOL Oh my. I didn't set out to rant. My hands just took over!
Cheers,
Mike Fidler
"I intend to live forever - so far, so good." Steven Wright
"I almost had a psychic girlfriend but she left me before we met." Also Steven Wright
"I'm addicted to placebos. I could quit, but it wouldn't matter." Steven Wright yet again.
|
|
|
|
|
1 Learn about "TDD"
2 Learn about "DDD"
3 Learn about "Agile"
4 Do job interview where you discuss the pros and cons of above
5 Start job
6 Use whatever NuGet packages have been shoehorned into the solution and your own framework as you don't like the 10 other frameworks the 10 previous devs have used, and all under Waterfall management that thinks it's Agile because they use JIRA.
|
|
|
|
|
F-ES Sitecore wrote: all under Waterfall management that thinks it's Agile because they use JIRA.
 Been there!
Marc
|
|
|
|
|
I've used Drunken Driven Design before, it's not all that. It's OK if you don't mind rewriting incomprehensible code.
It was broke, so I fixed it.
|
|
|
|
|
We are using it for one big 'field' of application(s) which share the same domain knowledge.
In general it's a good experience, mostly because all people involved commit themselves
to use (more or less) the same naming of the objects of the domain (I don't only mean 'object'
in terms of software, but also in the 'real world').
So even talking to management or to a salesman makes sense because there is kind of a common knowledge base.
Another big advantage is, that it's the first time I actually see code/projects really being
reused in different applications. But then, the reason for this may not be DDD, but a good design 
|
|
|
|
|
Duncan Edwards Jones wrote: any experience (pro or con) to share?
Cons =>
- More costly to setup, building the boilerplate stuff. Not worth for small and fast projects.
- It's difficult to design it with high performance on application heavily dependent on data. Complex domain models that require a lot of data to make it function may require a lot of data that can take some time to fetch from the database. At this point it's very important to analyze how to feed the domain model, as it should be clearly without dependencies, including data layer, as the application core.
Pros =>
- Although an initial setup may be a little more complex than a simple active record pattern or DB Oriented design, as the business complexity raises with new requirements, the complexity of the domain model increases at a similar rate when done properly. Other patterns tend to get exponentially complex and get very difficult to maintain as the business grows.
- Design focuses on the business problems, not on infrastructural restrictions (like relational database models), which can make your life a whole lot easier accommodating complex business rules and it's highly adaptable to business rule changes.
- Easy to maintain, very low coupling and a very high rate of reusable code, which helps preventing colateral damage (bugs) when something changes on the business. Here's where you can leverage the most of Object Oriented Programming and its benefits.
- Easy to couple with TDD. With a clear independence from UI, DB and other layers, you can focus on developing unit tests on the business logic, to ensure the core stays intact after domain changes.
- Having both data and behavior on the same object, it's much easier to implement SOLID principles and I specially like the separation of concerns it provides. Classes can be very concise, compact, easy to read, understand and use.
Well that's my experience designing DDD applications.
To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson
Our heads are round so our thoughts can change direction - Francis Picabia
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
