DDD & TDD. Part III

As the result of previous parts we have domain with core classes and services. Actually we can generate and process any amount of data with methods provided by domain services. But there are some issues:

  • How user will input data;
  • How data will reconstitute/persist.

Domain by nature and the general plan must be absolutely independent and free from technology aspects as GUI/user interaction (WPF, WinForms, Web) and the data layer implementation (MSSQL, MySQL, Oracle, etc.)

Layers

Step by step we realize that application should be multi layered. And there are minimum possible set of layers, as I see it:

  • Domain –business logic layer. In this layer described HOW to work with data.
  • Data layer. At this level implemented saving and recovering data to/from external data storage to domain objects. Extracting these actions in separate layer makes application more agile, i.e. it’s easy to deal with several different DB without changing other parts of the application.
  • Presentation layer. Here we say WHAT to do with data: define specific sequence of domain services and return calculated result to GUI. So, this layer connects Domain and Front End.
  • User Interface (Front End). This level can be console, win forms, web, even mental transmission to mind! =) Try to keep this layer as dumb as possible. No data changes, no application flow logic – only do what other says with any initiative.

Now when we know layers responsibilities, next goal is to understand how they interconnect with each other.

Continue reading

DDD & TDD. part II

Disposition

So we have domain classes with minimal set of properties and methods. Also we have several tests on these classes. The goal is to learn how deal with domain classes – i.e. write services which will do complex calculations and modifications. For example count students in selected course.

Domain services

Assume that one of the tasks is count classes for selected course and how many students in them.

Let’s think which domain classes known about each other:

  • “School” knows how many “Class”es it contains.
  • “Class” knows how many students it contains.

I think it will be enough for now. What is the easiest way that will implement most of novice? Add to “School” method:

public int CountStudent(int classNumber) { … }

But it is a bad idea because of next reasons:

  • It leads to growing responsibilities of “School” class and the result is coupling;
  • Became harder to maintain and change “School”;
  • Also can appear issues for test writing.

Continue reading

DDD & TDD. part I

Disclaimer

Article is a simple presentation of DDD and TDD in order to show how to deal with it and give an opportunity to start development according describing techniques. Those who already practice TDD and DDD,  please don’t be strict to words.

Magic abbreviations

DDD – Domain Driven Design, in few words it is a solution code manner. And your target is an extract main application logic, the core, in a separate independent module. Domain must be independent from specific technologies, it won’t relay on underlying data, graphical presentation and so on.

TDD – Test Driven Design, developing application by tests. “Test become before code”.

Both of these practices (maybe better to call it philosophy) come together in my projects and, to be honest, for me it’s hard to imagine their usage separately. But yes, you can use them absolutely separate and no one oblige you to apply them in every project together.

There is a dozen of books, articles and other stuff in any format and size. Somewhere it is simpler, somewhere with more complex vision. I wouldn’t like  to make a  historical excursion how DDD and TDD have been invented, because it’s easy to find out in web, to  google Eric Evance books or visit Martin Fowler site. I’d like to share my vision of subject in simple words. Tell how it helps, works, evolves and supports. I hope I can achieve the goal.

Okay, let’s take a closer tour by these techniques.

Continue reading