구조에 대해 이야기할 때 개발자들은 통상적으로 그들의 프로젝트 구조를 고려한다.청결, 포트와 어댑터, 양파...이 모든 것은 당신의 프로젝트를 어떻게 조직하는지에 관한 것이다.팀에서 그것을 계승하든지, 새로운 프로젝트나 재구성할 때 당신에게 더 의미 있는 방법을 시도해 보세요.중요한 것은 전체적으로 또는 일부 굵은 입도 서비스가 있고 약간의 관련 기능을 포함할 때 프로젝트 조직은 매우 중요하지만, 모든 기능을 위한 (마이크로) 서비스가 아니라 코드 단계에서 그것들을 분리하기를 원합니다.
일반적으로 여러 프로젝트를 포함하는 솔루션이 제공됩니다.

API - 컨트롤러 전용 및 공개 비즈니스 논리

도메인/코어 - 비즈니스 논리

인프라 - 인터페이스

지속성? -어떤 사람들은 데이터베이스에 있는 것을

으로 나누는 것을 좋아한다
그렇다면 이런 구조에 무슨 문제가 있는가?시몬 브라운의 강연을 듣고 계속해서 읽어 코드 예시를 얻자.

코드가 차트와 일치하지 않습니다.

두 가지 기능이 있는 API부터 시작하겠습니다.
일기예보
계산기 당신은 어떻게 구성 요소 그림을 그릴 것입니까?이런 거 맞죠?

당신은 당신의 코드를 어떻게 구성할 수 있습니까?내 추측으로는 이렇다.

API(프로젝트)

도메인(프로젝트)

일기예보(폴더)

계산기(폴더)

인프라

일기예보(폴더)

계산기(폴더)

분명히 일치하지 않는 것이 있습니다. 그렇습니까?너는 괜찮다고 말할 수 있다. 우리는 아주 좋은 폴더 구조를 가지고 있기 때문에 우리는 일을 분리하고 잘 조직한다.
네, 그런데 WeatherForecast 폴더의 어떤 내용이 Calculator 폴더의 다른 내용으로 호출되는 것을 막는 것은 무엇입니까?내부 관례와 규칙?수레를 끌다.그래, 이 모든 것이 도움이 될 수도 있지만, 요청에서 원하지 않는 관계가 잠입하려는 것을 보게 되면 더욱 분명해진다.

그럼 어떻게 세울까요?

다음과 같이 어셈블리 맵과 일치하는 것이 좋습니다.

API(프로젝트)

일기예보(프로젝트)

...

계산기(항목)

...

구체적인 기능의 개발자가 그 중의 코드를 어떻게 조직할지 결정할 수 있기 때문에 나는 특별히 세 가지를 넣었다.각 프로젝트에 도메인/인프라/폴더 구조가 있어야 합니까?기능이 간단하고 클래스가 적으면 어떤 하위 폴더도 갖고 싶지 않은 관례가 있을 수도 있다.너희 팀의 관례가 무엇이든지 상관없다.
몇 가지 뚜렷한 장점은 다음과 같다.

솔루션의 구조는 그림과 일치하기 때문에 코드가 있는 위치가 매우 뚜렷하다.

은 하나의 기능과 관련된 모든 코드가 하나의 프로젝트에 있기 때문에 서로 다른 기능 사이에 위험한 의존 관계를 구축하는 것이 더욱 어려워진다.

구성 요소 봉인

우리는 모두 포장이 무엇인지 알고 있지만, 우리는 보통 포장의 측면에서만 그것을 고려한다.Simon Brown은 구성 요소 레벨에서도 패키지를 제안합니다.REST API를 생각하면 사용자가 지정한 방식으로만 공개된 방법을 호출할 수 있도록 봉인됩니다.왜 구성 요소가 같은 조작을 실행하지 않습니까?
주입 인터페이스를 통해 이 점을 실현했기 때문에 호출자가 접근할 수 없다고 말할 수 있지만, 이것은 보통 사실이 아닙니다.일반적으로 우리는 API/핵심/실현 프로젝트 구조를 가지고 있으며, 우리의 모든 종류는 public이다.우리는 그들이 public이어야 한다. 왜냐하면 DI 설정은 보통 API 프로젝트에서 볼 수 있기 때문이다.
모든 구성 요소 구조의 새로운 프로젝트에 대해 우리는 더 이상 이 문제가 없다.실현 클래스는 private 또는 internal일 수 있기 때문에 다른 구성 요소에 숨겨집니다.예, 구성 요소에 DI를 설정합니다!

샘플 용액

GutHub의 샘플 솔루션 보기

니콜리치 보얀 / 모듈화

예시 해결 방안은 구성 요소/모듈에서 코드를 구성하는 방법을 보여 주었기 때문에 우리는 층을 나누는 방법을 완전히 피했다.

당신의'깨끗한 구조'는 여전히 층으로 나뉘어져 있습니다!

구조에 대해 이야기할 때 개발자들은 통상적으로 그들의 프로젝트 구조를 고려한다.육각형, 깔끔, 포트와 어댑터, 양파...이 모든 것은 당신의 프로젝트를 어떻게 조직하는지에 관한 것이다.팀에서 그것을 계승하든지, 새로운 프로젝트나 재구성할 때 당신에게 더 의미 있는 방법을 시도해 보세요.중요한 것은 전체적으로 또는 일부 굵은 입도 서비스가 있고 약간의 관련 기능을 포함할 때 프로젝트 조직은 매우 중요하지만, 모든 기능을 위한 (마이크로) 서비스가 아니라 코드 단계에서 그것들을 분리하기를 원합니다.
일반적으로 여러 프로젝트를 포함하는 솔루션이 제공됩니다.

API - 컨트롤러 전용 및 공개 비즈니스 논리

도메인/코어 - 비즈니스 논리

인프라 - 인터페이스

지속성? -어떤 사람들은 데이터베이스에 있는 것을

으로 나누는 것을 좋아한다
그렇다면 이런 구조에 무슨 문제가 있는가?듣다
View on GitHub
내 프로젝트 구조는 다음과 같습니다.

API(프로젝트)

구성 요소(구성 요소 그룹화를 위한 솔루션 폴더)

일기예보(프로젝트)

계산기(프로젝트)

어셈블리에서 노출되는 항목은 다음과 같습니다.

커넥터

커넥터 에

DTO 필요

의존항 주입 설정

API의 Startup.cs에서 확장 방법에 대한 호출만 추가하면 DI를 구성할 수 있습니다.

public void ConfigureServices(IServiceCollection services)
{
    services.AddControllers();

    services.AddComponentWeatherForecast();
    services.AddComponentCalculator();
}

다음은 확장 방법의 예입니다.

public static class ServiceCollectionExtensions
{
    public static IServiceCollection AddComponentWeatherForecast(this IServiceCollection services)
    {
        return services.AddScoped<IWeatherForecastService, WeatherForecastService>();
    }
}

마지막 말

나는 네가 이 포장 부품들을 좋아하길 바란다.그들은 정말 팀원들을 지름길로 가게 하기 어렵다.구성 요소가 서로 통신해야 한다면, 이것은 전혀 문제없습니다. 다른 구성 요소에서는 인터페이스와 DTO에만 접근할 수 있습니다.만약 당신이 구성 요소에 전면적인 서비스를 제공하기를 원한다면, 그것은 모든 것이 한 곳에 있기 때문에 매우 쉬울 것이다.
당신의 평론과 문제를 듣고 싶습니다.
읽어주셔서 감사합니다!