일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | ||||||
2 | 3 | 4 | 5 | 6 | 7 | 8 |
9 | 10 | 11 | 12 | 13 | 14 | 15 |
16 | 17 | 18 | 19 | 20 | 21 | 22 |
23 | 24 | 25 | 26 | 27 | 28 |
- django
- Java
- Software Engineering
- programming_book
- MySQL
- Programming
- Spain
- Kuala Lumpur
- Italy
- management
- hbase
- agile
- Python
- QT
- program
- web
- comic agile
- Linux
- hadoop
- history
- erlang
- Malaysia
- Book review
- RFID
- leadership
- psychology
- France
- Book
- essay
- ubuntu
- Today
- Total
목록Domain Driven Development (2)
소프트웨어의 목적은 도메인에서 이용자들이 직면한 문제를 해결하는 것이다. 그렇다면 이용자들이 직면한 문제를 해결하려면 무엇이 필요할까? 말할 필요도 없이, ‘이용자들의 문제를 정확히 이해하는 것’이다. 이용자들이 어려움을 겪는 부분이 무엇이고 해결하고자 하는 문제가 무엇인지 알려면 이용자들의 관점이나 생각, 그들이 처한 환경을 제대로 이해해야 한다. 다른 말로 하면, 이용자의 도메인을 접해야 한다. 모델은 현실에 일어나는 사건 혹은 개념을 추상화한 개념이다. 추상이란 여러 사물 혹은 개념에서 공통적인 것을 뽑아 파악하는 것으로, 현실의 모든 것을 반영하는 것이 아니다. 상황에 따라 취사선택이 필요하다. 무엇을 버리고 무엇을 취할지는 도메인에 따라 결정된다. 사건 혹은 개념을 추상화하는 작업을 모델링이라고..
개발 세계에는 여러가지 개발 방법론이 많다. 가장 유명한 건 아무래도 TDD이겠지만, 최근 가장 각광받는 건 DDD라고 생각한다. 그 이유는 아마 세상의 수많은 software는 대부분 현실의 문제를 해결하기 위해 만들었을텐데, 그걸 해결하는 게 여전히 힘들기 때문이라고 생각한다. 현실의 문제를 해결하는 게 아직도 힘든 이유도 여러가지가 있겠지만, 그 중 하나는 비즈니스를 하는 사람들과 개발자들간의 간극에 있다. 개발자들은 요구 사항에 맞춰 서비스를 만들(었다고 생각하)지만, 비즈니스를 하는 사람들은 내가 요구한 게 아니라는, 이 업계가 탄생한 순간부터 발생했던 문제. 애자일 방법론도 사실 이 문제 때문에 나오지 않았던가. 동작하는 소프트웨어를 전달하기 위해서. DDD는 이런 간극을 좁히기 위한 고민의 ..