I got a (few) comment by Colin on my previous post on the series that I had started.

He goes like this for me saying that I am the domain expert for the sample application I was building.

My main feedback would be that a DDD example done without an external domain expert probably isn’t a good idea. A few of us have tried this over the years and decided it wasn’t a great idea, I’d at the least indicate your using *some* of the patterns from DDD but not others (including the working with domain experts) and that this isn’t necessarily the sort of problem that suits a full DDD approach And for the application itself…

I don’t think it suits full DDD no, because you need domain experts and a complex enough problem domain to justify it. Doesn’t mean you shouldn’t do an example of the patterns and continue on as you are. If you learn from it and teach others then superb, however I’d just make sure to mention that DDD is about more than the patterns (repository/aggregate/value object/specification/service) and related technologies/practices (ORMs/TDD/POCO) that most people use.

Even I had a few doubts about the application when I had planned for it, so from my next post ( for the series ), I wont be talking about DDD anymore. So what changes? Nothing really, from the project structure to the tools, nothing changes. Having a domain layer doesn’t mean that the application uses DDD and segregating the project structure as I have gives a clear understanding with separation of concerns. Although I might have have to change a few things that I had thought of using like the Aggregates and a few. I don’t want that sort of complexity as of now.

And about DDD, I really like the way it helps you build a software. I have barely touched the surface of it and will surely blog about it in the future.

P.S. The sample application will no longer be called as DDDBlog. This site is running on a custom blog I wrote which I had named MPS ( MyPersonalSite ), so may be I will call the sample application as MPBlog.