I must say, emphatically, that Domain-Driven Design by Eric Evans should be a required read by any software engineer in the field that is using an object-oriented language (I canâ€™t speak outside of that yet).
"This book belongs on the shelf of every thoughtful software developer."
This book has been out for awhile â€“ I first read Applying Domain-Driven Design and Patterns: With Examples in C# and .NET by Jimmy Nilsson â€“ and although it was a good starter book, in retrospect, it would have been better for me to start from the source.
To me there is a ladder of growth emerging:
1. First the goal of writing code that follows good object oriented design. ie. loosely coupled, encapsulation, programming w/interfaces, etcâ€¦
2. Then we see patterns emerge in that code base – â€˜factory pattern, strategy pattern, inversion of controlâ€™ â€“ not even as much as â€˜in codeâ€™ but as a way to â€˜talk about codeâ€™. When one dev says to another â€˜we need to use a factory hereâ€™ â€“ itâ€™s a common language.
3. Once these start to emerge, there is an architectural awareness â€“ a â€˜how do I fit these pieces togetherâ€™. DDD by Eric Evans (and Patterns of Enterprise Application Architecture by Martin Fowler) is the next great place to explore.
What is interesting is several projects Iâ€™ve seen were driven from a technology perspective and not from a domain driven one â€“ and have required someone coming in and â€˜savingâ€™ the project.
In my current project itâ€™s been an evolving model, expanding and refactoring as I have learned more of the business and itâ€™s rules. Our jobs as developers are twofold â€“ be experts in the technologies we work in , but more than that â€“ to learn how businesses work â€“ to relate to customers, etcâ€¦ itâ€™s quite a task! Many times I see organizations attempt to conquer the problem through the technology only without really grasping the domain being modeled.
I started with the layered approach, and honestly began to learn how to shape the parts as the knowledge of the domain began to shape and form. Evolving is the keyword, to me though â€“ itâ€™s a learning process, there are times that difficult decisions are made when shaping the code, and yet when trying to stick close to first being conscious and aware of â€˜howâ€™ Iâ€™m writing the code. Having a DDD up front, separating the domain, repositories, understanding â€˜specificationâ€™, â€˜factoriesâ€™, etcâ€¦ all produce an environment where the software can shape and grow without becoming too unwieldy. Eric Evans helps to shape and form his experience is a way that provides insight and wisdom into domain-driven development.
(see also http://domaindrivendesign.org/ )