Well-built service API may be a game changer. In both client-server & server-server scenario, especially if you're following the latest trend of building fine-grained, loosely coupled (micro)services. I've seen several attempts, in different languages, for different domains & running on different platforms - regardless of these differences, there are some common anti-patterns & mistakes that could quite easily be avoided. My goal in
Here comes another post in "remarks from awesome DDD Europe 2016" series. If you find it boring or not really revealing, I'm the one to be blamed - some ideas, especially related to modelling & design are truly hard to convey.
Many software developers are really hooked up by DDD - pretty much everyone I know who's enthusiastic about DDD is a software developer,
Do you know any software craftsmanship practitioners who got fascinated by DDD? By its cleaniness, simplicity or completeness? People who have found the way proposed by Evans their missing tool for describing complex domains in a simple way? I know quite a few & I believe you do as well.
Where are these DDDers?
But how many of those people do actually apply these
I've already promised myself some time ago:
"No more conference reviews, chap."
But I'll start 2016 with breaking this rule once again, just so I can tell you that ... DDD Europe 2016 was way better than I expected.
No worries though, I'll try to be as brief as possible:
Guys (& gals?) of DDD Belgium have proven that they are no pushover, but the
I keep forgetting how diverse & "flavor-rich" is our industry (software development). Not just in terms of tools, but also outlooks, opinions & overall openness to change. Within last two weeks I was exposed to software engineers ...
- ... complaining on Microsoft going to fast with their web stack - they didn't manage to fully embrace MVC yet (!) & there's the vNext thing around the corner
I'm spending a lot of time with Pluralsight - actually they publish more interesting stuff than I can comprehend in my limited timeframe. Once in a while I find there a course that may not be in my (still wide, I think) area of direct interest, but ... it's either a source of inspiration / good ideas or just a redirection to something I've previously didn't
Uncertainty, uncertainty everywhere
You know what's the most common error people make when trying to embrace DDD? They tend to focus on DDD's specific DSL (terminology, composition) - entities, boundaries, aggregate roots, etc. because they think that this particular modeling model (OMG, recurrence detected, stack overflow comin' ...) is a game changer. But it isn't.
It's useful (it's an ubiquitous language for modelers :)) & makes
Private advertisement mode ON
On 11th of Dec I'll be presenting some introductory stuff about Domain Driven Design at WG.NET (Meetup event link is here). If you were always wondering what's the DDD fuss about & why people still keep talking about the famous "blue book": here's your opportunity to find out.
You know what's even better? There'll be a raffle - every
If you know me in person, you most likely already know that I'm batshit crazy about DDD (Domain Driven Design, not Degenerative Disc Disease ...). As DDD is the kind of topic everyone speaks about but only few actually use this method in practice, I've decided to share some real-life lessons learned with The Internet (I mean you: The Reader). It doesn't mean that I