既存のチームでDDDとTDDを実装する

Question

私の最後のプロジェクトでは、ビジネスロジックが動的で要件が事前に取得できないという意味で、アプリケーションがかなり複雑であるため、D-Dレイヤーを適用しました。

これは、アジャイル開発にうまく適合し、繰り返しに沿ってドメインロジックを徐々に理解するのに役立ちます。我々は、期待される行動を理解し、ドメインモデル（DDD）を開発するためにTDDを使用した。

私のチームでは、チームメンバーの中にはOOPの基本やSOLID、Refactoringなどのプラクティスについて実際に認識していないという問題があります。 SQLプロシージャーを使用してビジネス・ロジックを実装する方がより快適です。また、すべての概念を学ぶ必要があるため、生産性にも影響します。

問題は、これは通常、他のソフトウェアハウスで起こりますか？

Answer 1

はい、発生します。

DDDには強力なスキルと規律が必要です。

開発者は通常、ストアドプロシージャと手続き型プログラミングに慣れています。 ほとんどの場合、devはOOPを作ることを "考える"が、実際には多くの手続き型プログラミングを行っています。

リファクタリング

をかぐ

• OOP
• ユニットテスト
• コード：

  は、だから私は学習にいくつかの時間を費やすなどをテーマにチームに力を与えるためにDDDを行う前に示唆しますパイロットプロジェクトでDDDを試してみてください。