[JAVA] Probieren Sie das Gesetz der Abhängigkeitsumkehr mit mehreren Spring Boot-Projekten aus

Was

――Ich habe Clean Architecture gelesen und wollte sehen, was passiert, wenn ich einige Szenarien mit Spring Boot implementiere.

Karte

• (Das Folgende ist eine vereinfachte grobe Karte, und das Buch kann so etwas nicht sagen oder sagen)
• Eine Komponente ist eine Sammlung verwandter Funktionen. --Komponenten haben eine Abstufung vom Detail zum Wesen
• Details können ersetzt werden. Wo die Daten gespeichert werden (DB, Datei, Cloud-Speicher) und wie sie angezeigt werden (WEB, Konsole, PDF usw.), wird detailliert beschrieben.
• Im Wesentlichen handelt es sich um eine Entität oder einen Anwendungsfall, der eine Entität verwendet.
• Das Unternehmen verfügt über die wichtigsten Geschäftsregeln und Daten.
• In Anwendungsfällen gelten anwendungsspezifische Geschäftsregeln. (Definieren Sie, wie die Entität verwendet werden soll, unabhängig von Details.)
• Je weiter von der Eingabe / Ausgabe entfernt, desto höher ist der Pegel (= je höher die Essenz. Je höher der Pegel der Entität).
• Komponenten auf höherer Ebene sollten keine Komponenten auf niedrigerer Ebene kennen. (Entität ist vom Anwendungsfall unabhängig, Anwendungsfall ist nicht detailliert)
• Wenn die obere Ebene Kenntnis von der unteren Ebene erlangt, kann diese durch eine Abhängigkeit von der Abstraktion ersetzt werden, indem eine Schnittstelle in der Mitte verwendet wird. (Das Gesetz der Abhängigkeitsumkehr) --Beispiel) Wenn in einem Anwendungsfall "eine Entität speichern", darf die Tatsache, dass es sich um "in MySQL" handelt, nicht in der Anwendungsfallimplementierung erscheinen. Speichern Sie die Benutzeroberfläche, indem Sie sie "irgendwo speichern".
• Das Gesetz der Abhängigkeitsumkehr selbst erwähnt nicht, wie Komponenten getrennt werden sollen. Es gibt drei Arten von Trennmethoden. (Quellenebene, Bereitstellungsebene, Serviceebene)
• Die Quellenebene ist die Klassenstruktur in einem einzelnen Projekt. Auf Bereitstellungsebene gibt es separate Jars. Auf Serviceebene steigt die Isolationsstufe und die Kommunikation ist ohne Netzwerkkommunikation nicht möglich.
• Versuchen Sie, die Verbindung auf Bereitstellungsebene mit mehreren Spring Boot-Projekten zu trennen, um zu sehen, was mit den pom.xml-Abhängigkeiten passiert. ―― Je höher der Trennungsgrad, desto höher die Entwicklungs- und Verwaltungskosten. (Wie verwalten und verbreiten Sie beispielsweise die funktionsfähige Version, wenn Sie das Glas teilen?) Die monosilische Konfiguration ist nicht absolut schlecht. (Wenn Sie jedoch die Grenzen nicht berücksichtigen, können Sie sich bei Bedarf nicht mehr trennen.) ――Ein Beispiel für den Vorteil der Trennung ist, dass Sie Stecker und Details wechseln können, ohne sie zu kompilieren.

Projekt zu erstellen

• In diesem Beispiel sind die Namespaces von my-repository 1 und 2 identisch.

Abhängigkeiten in pom.xml

--my-running verwendet my-repository1. my-repository2 wird nicht verwendet.

Quellbeispiel (mein Geschäft)

SomeEntity.java

package com.example.demo.business;

public class SomeEntity {
	public int id;
	public String name;
}

SomeUseCase.java

package com.example.demo.business;

@Component
public class SomeUseCase {

	@Autowired
	private MyRepositoryInterface repo;

	public void doSomething(String name) {
		SomeEntity entity = new SomeEntity();
		entity.name = name;

		repo.save(entity);
	}
}

MyRepositoryInterface.java

package com.example.demo.business;

public interface MyRepositoryInterface {
	public void save(SomeEntity someEntity);
}

Quellbeispiel (my-repository1)

MyRepositoryImpl1.java

package com.example.demo.repository;

import org.springframework.stereotype.Component;

import com.example.demo.business.MyRepositoryInterface;
import com.example.demo.business.SomeEntity;

@Component
public class MyRepositoryImpl1 implements MyRepositoryInterface {

	public void save(SomeEntity someEntity) {
		System.out.println("save to mysql." + someEntity.name);		
	}

}

Quellbeispiel (my-repository2)

MyRepositoryImpl2.java

package com.example.demo.repository;

import org.springframework.stereotype.Component;

import com.example.demo.business.MyRepositoryInterface;
import com.example.demo.business.SomeEntity;

@Component
public class MyRepositoryImpl2 implements MyRepositoryInterface {

	public void save(SomeEntity someEntity) {
		System.out.println("save to file." + someEntity.name);		
	}

}

Quellbeispiel (mein Läufer)

MyRunnerApplication.java

package com.example.demo.runner;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;

@SpringBootApplication(scanBasePackages={"com.example.demo.runner, com.example.demo.business, com.example.demo.repository"})
public class MyRunnerApplication {

	public static void main(String[] args) {
		SpringApplication.run(MyRunnerApplication.class, args);
	}
}

MyRunner.java

package com.example.demo.runner;

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.CommandLineRunner;
import org.springframework.stereotype.Component;
import com.example.demo.business.SomeUseCase;

@Component
public class MyRunner implements CommandLineRunner{
	
	@Autowired
	private SomeUseCase someUseCase;
	
    @Override
    public void run(String... args) throws Exception {
    		System.out.println("running runner...");
    		
    		someUseCase.doSomething(args[0]);
    }

}

Einfallsreichtum, um diese mit Spring Boot zu bewegen

--scanBasePackages listet alle Namespaces auf.

• Außer für meinen Läufer, der der Startpunkt ist, habe ich Folgendes aus pom.xml gelöscht. Daher war ich wütend, dass es zum Zeitpunkt der `` `mvn install``` kein Hauptprojekt gab

pom.xml

	<build>
		<plugins>
			<plugin>
				<groupId>org.springframework.boot</groupId>
				<artifactId>spring-boot-maven-plugin</artifactId>
			</plugin>
		</plugins>
	</build>

Startmethode

--Erstelle ein Glas für jedes Projekt außer für meinen Läufer. `mvn install -DskipTests = true `

• Starte meinen Läufer.

init.sh

$ mvn spring-boot:run -Dspring-boot.run.arguments="hello"
...
running runner...
save to mysql.hello

Eindrücke davon zu machen. Verdienstausgabe

• Indem Sie andere Projekte (mein-Läufer, mein-Repository1) aus der Essenz (mein-Geschäft) nicht verfügbar machen, können Sie die Regel "Essenz darf nicht von Details abhängen" durch Kompilieren erzwingen.
• Sie können das Repository wechseln, indem Sie pom.xml von my-runnner neu schreiben, ohne es zu kompilieren.

Eindrücke davon zu machen. Nachteile

• Die Entwicklungseffizienz sinkt. Wenn es nicht gut funktioniert, gibt es verschiedene Möglichkeiten, so dass es schwierig ist, es zu isolieren. Es wird noch schwieriger, wenn Sie mit der Verwaltung der Version von jar beginnen.

Was ich nicht verstanden habe

--Für scanBasePackages, wenn es mehrere detaillierte Module gibt, die möglicherweise in Zukunft gewechselt werden, sollte ich sie auflisten, wenn ich ohne Kompilieren wechseln möchte?

• Ich habe erwartet, dass die IDE sich um mich kümmert, ohne jedes Mal "mvn install" ausführen zu müssen, wenn ich die in der Entwicklung befindliche Quelle ändere, aber es hat nicht funktioniert. Es scheint, dass die Einstellung irgendwo notwendig ist.

Zukünftige Entwicklung

--Was ist, wenn Sie den Anwendungsfall und die Entität in separate Gläser trennen möchten? --Wie kann ich die Frühlingsanmerkungen in meinem Anwendungsfall entfernen? ――Was passiert, wenn Sie den Anwendungsfall-Ausgabeport (I), den Anwendungsfall-Eingabeport (I) und den Anwendungsfall-Interaktor einführen, die in Kapitel 22 des Buches aufgeführt sind?