[JAVA] Stoppen wir die göttliche Entität, die alle Statistiken in einer Klasse ausdrückt!
Ich habe es nur mit Schwung geschrieben! Wie der Titel schon sagt!
Wenn ich mir die Geschichte anhöre oder während der Lernsitzung auf Twitter schaue, habe ich plötzlich das Gefühl, dass es oft Entitäten gibt, die die Nomenklatur, die sie als Klasse finden, verwenden und alle datenähnlichen Dinge um sie herum hineinwerfen. Ich schrieb auch, als ich ein Anfänger war w
Code sofort
UserStatus.java
public enum UserStatus {
Applying, //Bewirbt sich
Using, //in Benutzung
Leaved, //Zurückgezogen
BlackListed, //schwarze Liste
Erased, //Löschen
}
(Nur) Ich habe eine Klasse namens "Benutzer" mit einem solchen Zustand in einem ausgedrückt!
Ich denke, es ist in der Phase üblich: "Da es sich um DDD handelt, erstellen Sie eine Klasse namens User und schreiben Sie die Verarbeitung dort." Ich bin mir sicher, dass es anfangs nicht in einem guten Zustand war, aber ich verstehe, dass es gefährlich wurde, während ich Analysen oder Service-Wachstum durchführte. Unun
User.java
public class User {
private UserId userId;
private UserCourse userCourse;
private UserStatus userStatus;
private ApplyDate applyDate;
private Optional<UseStartDate> useStartDate;
private Optional<LeaveDate> leaveDate;
private Optional<EraseDate> eraseDate;
public User apply(UserCourse userCourse) {
return new User(
new UserId(), userCourse, Applying, new ApplyDate(), Optional.empty(), Optional.empty(), Optional.empty()
);
}
public User useStart() {
if (userStatus != Applying)
throw new RuntimeException("not applying");
return new User(
userId, userCourse, Using, applyDate, Optional.of(new UseStartDate()), leaveDate, eraseDate
);
}
public User courseChange(UserCourse userCourse) {
if (userStatus != Using)
throw new RuntimeException("not using");
return new User(
userId, userCourse, userStatus, applyDate, useStartDate, leaveDate, eraseDate
);
}
public User leave() {
if (userStatus != Using)
throw new RuntimeException("not using");
return new User(
userId, userCourse, Leaved, applyDate, useStartDate, Optional.of(new LeaveDate()), eraseDate
);
}
public User blackListIn() {
if (userStatus != Using)
throw new RuntimeException("not using");
return new User(
userId, userCourse, BlackListed, applyDate, useStartDate, leaveDate, eraseDate
);
}
public User blackListOut() {
if (userStatus != BlackListed)
throw new RuntimeException("not black listed");
return new User(
userId, userCourse, Using, applyDate, useStartDate, leaveDate, eraseDate
);
}
public User erase() {
if (userStatus != BlackListed)
throw new RuntimeException("not black listed");
return new User(
userId, userCourse, Erased, applyDate, useStartDate, leaveDate, Optional.of(new EraseDate())
);
}
}
Der zu verwendende Code ist wie folgt
UserService.java
public class UserService {
public void leave(UserId userId) {
User usingUser = userRepository.find(userId);
User leavedUser = usingUser.leave();
userRepository.leave(leavedUser);
billing.stop(leavedUser.getLeaveDate().get());
...
}
}
Uhe ~ scharf ~
Der Code ist lang! Selbst wenn Sie es kompilieren, erhalten Sie eine Ausführungsausnahme! Ich meine, Domain-Logik ist Nani!
** Dies ist nicht fast ein DTO ~? ** ** **
Teilen wir die Klasse nach dem Staat auf!
Ich werde die Implementierung weglassen, aber lassen Sie uns die Klasse nach dem Zustand aufteilen.
Es gibt zwei Punkte!
- In kleinere Teile teilen, ohne sich nach Status zu bemühen
- Haben Sie keine Werte, die nur in einem bestimmten Zustand gehalten werden können, und stellen Sie sicher, dass Sie sie haben, wenn Sie sie haben.
- Eliminieren Sie "Optional" so weit wie möglich
Die Hauptvorteile!
- Beseitigt Ausführungsausnahmen, die aufgrund eines falschen Status ausgeführt werden
- Beseitigt die Möglichkeit von Ausführungsausnahmen wie "leavedUser.getLeaveDate (). Get ()"
- Klären Sie die Verarbeitung, die in einem bestimmten Zustand durchgeführt werden kann
- Klären Sie, welche Übergänge von was
Es ist einfach, aber sehr effektiv. Probieren Sie es aus!
Natürlich ist es nicht Tech-First, sondern Modellierung.
Ich habe den Status im Beispiel verwendet, aber es hängt von der Modellierung ab. Die Anwendungsfälle und der Grad der geschäftlichen Auswirkungen müssen unterschiedlich sein.
Und diese Trennung ist nicht "das ist DDD!", Sondern "nur ein Ausgangspunkt"! Auf diese Weise können Sie das Modell verkleinern, von dort aus analysieren, die Logik sortieren und sammeln!
In diesem Beispiel wird beispielsweise der Abrechnungsstopp (billing.stop (...)) beginnend mit LeavedUser modelliert.
Wenn Sie ein wenig vorsichtig sind, auch wenn Sie glauben, eine Entität erstellt zu haben, handelt es sich nur um ein DTO. Seien Sie also vorsichtig!
Übrigens habe ich vor ungefähr zwei Jahren einen ähnlichen Artikel geschrieben, wenn es Ihnen gefällt, bitte. [Es fühlt sich gut an, verschiedene Klassen für dieselben Tabellenwerte vorzubereiten. #Fall 2 - Aktualisieren Sie den Status einer Klasse](https://qiita.com/suzuki-hoge/items/b8eb2fe9fbe551cfede4#%E3%82%B1% E3% 83% BC% E3% 82% B92-% EF% BC% 91% E3% 81% A4% E3% 81% AE% E3% 82% AF% E3% 83% A9% E3% 82% B9% E3 % 81% AE% E7% 8A% B6% E6% 85% 8B% E6% 9B% B4% E6% 96% B0% E3% 82% 92% E3% 81% 99% E3% 82% 8B)
Recommended Posts