Psychedelic Panorama of Foo

Pitfalls in DSL Design When Following a DDD Approach

아녕하세요. This is really a response to Warner's post. My friend, Warner has a blog entry on steps for getting started with DSL's where he outlines some very useful and basic steps for creating your own DSL. Warner's is great. My ideas are not necessarily a process or saying that Warner's process is bad. It is an outline of traps to stay away from. I think it is the systematic complement to Warner's steps (assuming you are also using a Domain Model and Domain-Driven Design.) You could say that while using Warner's steps, you should be weary of these things.

Warner has taken a very practical stance in his post. Any good programming practices are put to work in his steps. Prototyping, Unit testing, iterative and incremental steps on requirements to code. It definitely puts DSL's into a good perspective with concise direction that people might not right away catch on to.

I want to outline some ideas I have about designing software towards a given domain. A lot of people have very good ideas about ways you can go about it, but I want to be the voice that says what NOT to do.

• Losing focus of the domain. Domain is foremost in DDD and DSL. It should be foremost when using a DDD approach or creating a DSL.
• Neglecting Experts. Domain Experts bring the domain requirements to the surface.
  • Community involvement is a welcome friend. A mob of millions of people can't possibly be wrong.
  • Marketing is the devil. If you have to convince and maybe even deceive your user base into thinking it's good, then it's probably time to start over.
  • Users aren't always people. In the end it's all about users ... and the interface.
• Becareful of Overdesign. It's too easy to get carried away.

Eric Evans wrote about his experiences in gleaning software requirements from domain experts, and explained that it was a very loooooong process of learning the domain and building an Ubiquitous Language between the developer and the domain experts. All that hard work is for naught if one loses sight of the domain.

Building the Domain Model is part of the design process along with requirements gathering. You can't build the Domain Model in a day, a week, or even a month. This design is part of an iterative and incremental development process. This means you stay focused on it and keep coming back to refine it until it is perfect. Warner noted iterations in prototyping, but this is beyond that. This begins encapsulating the entire design before getting to a prototype.

After the Domain Model is complete, it represents a foundation of the system. It defines the business behavior and structure, and is a central authority on the specification. This goes for the developer and the domain experts. That means it will be consistently referred to, so keep up with the Domain or you're lost.

Eric Evans brought up an interesting concept of Ubiquitous Language. The concept arose as a result of developers communicating with domain experts about a business process and software system. Ubiquitous Language is intended as a common language within the domain where domain experts and others can openly communicate about the Domain. This is an alternative to methods like translation where Domain Specifics can be lost. Trying to translate the Domain into a DSL, is basically the wrong way to go. You will lose sight of your domain. It is better to build up an Ubiquitous Language and go from that using the Domain Model. That way there is a firm structure to refer back to. It is like affirmation about the language you are building.

Domain Language, the home of Eric Evans, expresses in its mission statement "Streamline development and produce software that is deeply connected to its users." Users aren't always people. A user could be a component or a service. It might even be part of a whole other system. The key is interfacing with your software. The DSL represents your interface that allows you to get your users "deeply connected."

See also the previous note about Ubiquitous Language.

Designs can take awhile. It is good to accomplish more at the start of a project, but there is a plateau where one ends up just wasting time. It is the same with DSLs. Your DSL should be simple, intuitive, and as little thought from a developer as possible since it should matche the needs of the Domain user more than the developer. It is easy to add things to the DSL that may never be used simply be cause the developer thinks they could be or because "it's consistent."

Tracking back to http://www.warneronstine.com/blog/articles/trackback/296

레이블: ddd, design, domain, driven, engineering, software

작성자: r351574nc3  # 12:34 오후